From patchwork Tue Jun 18 22:45:20 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrii Nakryiko X-Patchwork-Id: 13703112 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 A0351C2BA1A for ; Tue, 18 Jun 2024 22:45:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4EECE6B0349; Tue, 18 Jun 2024 18:45:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 474856B034A; Tue, 18 Jun 2024 18:45:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 314836B034B; Tue, 18 Jun 2024 18:45:43 -0400 (EDT) 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 037366B0349 for ; Tue, 18 Jun 2024 18:45:42 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 7AB45160B7A for ; Tue, 18 Jun 2024 22:45:42 +0000 (UTC) X-FDA: 82245492924.12.52B466F Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf11.hostedemail.com (Postfix) with ESMTP id 22EBF40002 for ; Tue, 18 Jun 2024 22:45:39 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=jkx+BEUm; spf=pass (imf11.hostedemail.com: domain of andrii@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=andrii@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=1718750737; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=pr/fv0ckxhWR6mlagUsulw9zLq7bdT+8t88N5DpZzzA=; b=ad/R1oP416X2AUnpQqF871Gd0Z/YJA2sJAIvMunuN+d0OqX8qUV8Q27y7tL5hvUT0NocUY uKO6n6twurG/MEjdSUg48/Blcv9f03fFaQ2wL71akm7XjHet5YcoIzbc2HC9NqaYiJoq+O iiwZVixehoQc+fo2Fijlc2uqWG16P6o= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=jkx+BEUm; spf=pass (imf11.hostedemail.com: domain of andrii@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=andrii@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718750737; a=rsa-sha256; cv=none; b=RnARTUPGYhCMHIvpUUo+bouI63csKapSQIf9mIoCZYeMdiIR2ohMFJFiN7je79VqCc7ZFd uMbj8jKzuUCkicTioy78dRioagHr5aFFFCMKgHd8tt1qfVnVn/2Qq1+aIimSpaeQ26f1W/ WW7mICifSKkswiSYpLXuESORHGVuETg= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id A6ECFCE1C43; Tue, 18 Jun 2024 22:45:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C94E8C4AF49; Tue, 18 Jun 2024 22:45:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1718750735; bh=b8KoHPdCbnvChHG05PMTrqcngJcnOaTMuFGj6VIsl38=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jkx+BEUmUtL0KzQE6yq+Z+VsGFwV14uAF6j7cuHLez9pT4S/raH5zqhjTuZWITNP6 pCtXdof9TOAFWXlw36uqcOMVvWrm27/sz5svx4waMOc72J6usnfPz2RHx5lwhvmQZd of/ebZN+uegBPTT0vwfGYzuaYEQKjzofmJkOnEV8wfIrGXVQU4C8GEKA/FXBNOAOGa TTE0HDNbT4QAkSaTQrSiWU317sb5eoAZGPGt/EjP4xSTO6cLTD6/yIO7hpf06HH1O0 WMvpuZBV2+9WYw6meBmD3YCJjPTRnluFM3qGfNBOp4HKBfvPqpYnMhvKkgRRPSf+g0 UPktbl6oSO0Yg== From: Andrii Nakryiko To: linux-fsdevel@vger.kernel.org, brauner@kernel.org, viro@zeniv.linux.org.uk, akpm@linux-foundation.org Cc: 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, Andrii Nakryiko Subject: [PATCH v5 1/6] fs/procfs: extract logic for getting VMA name constituents Date: Tue, 18 Jun 2024 15:45:20 -0700 Message-ID: <20240618224527.3685213-2-andrii@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240618224527.3685213-1-andrii@kernel.org> References: <20240618224527.3685213-1-andrii@kernel.org> MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 22EBF40002 X-Stat-Signature: omytwr4ckzuw54q4b1dc4fsakh349jes X-HE-Tag: 1718750739-898 X-HE-Meta: U2FsdGVkX1+zSo6Xulip45jyonGPVn7rSX0quT5STeH4IiVNkYOEMWaVB0cxGm/WcTzVEbG0dusv4VtOA072wP3Yn1WIQod02YMXLQ31Tn3c3/FTeUVM3EDa/2Mp7MLoV0+YFbiiUuc5QxOszrS7CRVC1nBhYBBXbDsxY9KuI2ZU5ME94VhJHeQdZvCF80I5vKsYdXCqaWnP7IdcAM9bhxHWEJGp0k723qZj40w6FKqmE22FGpD9uNpuma9HhKKWyoULmquvcLZ7euUr+ViR+d9wYk2GIpPM0PKX82bjgChKN+zXagH/MzDBkdavjmi7acXP6UsK0HXbW31+zsshpuKX80hSUEzR4/WM1dGUPBdjdmTETe8ImeATwJ2RnwL3/atGT2qG2SCsEtXWOrcjdaz8bk1j6mAH2k67xpDiO5qIzk53UfaQzj1utFWZIWha63xOKE8Um67ac0005hYuEza9BR/hRfbYOvAhp2rC4tydTgGy9kN4b4y5hfuwGBTG9/kQnATujYvv9WlZVCTpCPDpyEUVyZeHrN3lmmBKpIvGFHdsIYm3RsXzO+YDLY1PfRTShnEiNqgb8tLYY4SSCeO1CpgW0GcpvW+z+aQXr2Aw/NsOoj3iVzQ0K65gzCMQawUoPpiuOFNESmMFguSVS1z9qYpHhJXKzIFKm4HdTUCY4af/1epIDgqrynNG+BHvg5n+tK46K+eUL+UmRwEQB5KCxG10x2dX7oIKgY/PPjC36oSB51jakauxdcRolfSlMmSiRvuyVh1ULbo3UpA2/PDSNEflqamF3FY+UZPJ8qzkWMpEBCx1Z87NCd0HlprvfTp1uqxHbf2woIsa1CIzxqrCouNNzYMBbj4oqulsIVdsl+7Ni+NY6EZZKwuyrFrY6WD4JgIV2VvqC0JvCSYfoiqLck8Zz+jwm8paMwUlslgMUb+wkVRFCZwWGX9NXzdRCCUrmSWdYu4U0FbUbLP xc4GZ6P2 QLbw3PEMdKMhvMnLgUxTvr5otNftkPum6Op5nJUzWbEZevqWzCsUIe06uzNJ4R1Go0LbypJG5FKfEgZNSzz1uTU2b7iPE3kotBjBtoVW+5dJw1IE0/euVqAtQT/llguRXS+An6RHfNeRwLT5bcIXeGskxjwKZBuWqhGHRZhvm8/NLR7ayJMEvpDsJVCcRsTUQS4il4OQd7cOnZ8YGX500xemAm40iL9m6OAQxVUqMOBCSrEqqAnO8vf3iQcUYVfUd4Em5+3qgDgpEGYGICeR/OfJdMy75o+4jSKiZTO4IsUZ9L07SOmBwy4/L5igKoujNOo3L 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: Extract generic logic to fetch relevant pieces of data to describe VMA name. This could be just some string (either special constant or user-provided), or a string with some formatted wrapping text (e.g., "[anon_shmem:]"), or, commonly, file path. seq_file-based logic has different methods to handle all three cases, but they are currently mixed in with extracting underlying sources of data. This patch splits this into data fetching and data formatting, so that data fetching can be reused later on. There should be no functional changes. Signed-off-by: Andrii Nakryiko --- fs/proc/task_mmu.c | 125 +++++++++++++++++++++++++-------------------- 1 file changed, 71 insertions(+), 54 deletions(-) diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index 93fb2c61b154..507b7dc7c4c8 100644 --- a/fs/proc/task_mmu.c +++ b/fs/proc/task_mmu.c @@ -239,6 +239,67 @@ static int do_maps_open(struct inode *inode, struct file *file, sizeof(struct proc_maps_private)); } +static void get_vma_name(struct vm_area_struct *vma, + const struct path **path, + const char **name, + const char **name_fmt) +{ + struct anon_vma_name *anon_name = vma->vm_mm ? anon_vma_name(vma) : NULL; + + *name = NULL; + *path = NULL; + *name_fmt = NULL; + + /* + * Print the dentry name for named mappings, and a + * special [heap] marker for the heap: + */ + if (vma->vm_file) { + /* + * If user named this anon shared memory via + * prctl(PR_SET_VMA ..., use the provided name. + */ + if (anon_name) { + *name_fmt = "[anon_shmem:%s]"; + *name = anon_name->name; + } else { + *path = file_user_path(vma->vm_file); + } + return; + } + + if (vma->vm_ops && vma->vm_ops->name) { + *name = vma->vm_ops->name(vma); + if (*name) + return; + } + + *name = arch_vma_name(vma); + if (*name) + return; + + if (!vma->vm_mm) { + *name = "[vdso]"; + return; + } + + if (vma_is_initial_heap(vma)) { + *name = "[heap]"; + return; + } + + if (vma_is_initial_stack(vma)) { + *name = "[stack]"; + return; + } + + if (anon_name) { + *name_fmt = "[anon:%s]"; + *name = anon_name->name; + return; + } +} + static void show_vma_header_prefix(struct seq_file *m, unsigned long start, unsigned long end, vm_flags_t flags, unsigned long long pgoff, @@ -262,17 +323,15 @@ static void show_vma_header_prefix(struct seq_file *m, static void show_map_vma(struct seq_file *m, struct vm_area_struct *vma) { - struct anon_vma_name *anon_name = NULL; - struct mm_struct *mm = vma->vm_mm; - struct file *file = vma->vm_file; + const struct path *path; + const char *name_fmt, *name; vm_flags_t flags = vma->vm_flags; unsigned long ino = 0; unsigned long long pgoff = 0; unsigned long start, end; dev_t dev = 0; - const char *name = NULL; - if (file) { + if (vma->vm_file) { const struct inode *inode = file_user_inode(vma->vm_file); dev = inode->i_sb->s_dev; @@ -283,57 +342,15 @@ show_map_vma(struct seq_file *m, struct vm_area_struct *vma) start = vma->vm_start; end = vma->vm_end; show_vma_header_prefix(m, start, end, flags, pgoff, dev, ino); - if (mm) - anon_name = anon_vma_name(vma); - /* - * Print the dentry name for named mappings, and a - * special [heap] marker for the heap: - */ - if (file) { + get_vma_name(vma, &path, &name, &name_fmt); + if (path) { seq_pad(m, ' '); - /* - * If user named this anon shared memory via - * prctl(PR_SET_VMA ..., use the provided name. - */ - if (anon_name) - seq_printf(m, "[anon_shmem:%s]", anon_name->name); - else - seq_path(m, file_user_path(file), "\n"); - goto done; - } - - if (vma->vm_ops && vma->vm_ops->name) { - name = vma->vm_ops->name(vma); - if (name) - goto done; - } - - name = arch_vma_name(vma); - if (!name) { - if (!mm) { - name = "[vdso]"; - goto done; - } - - if (vma_is_initial_heap(vma)) { - name = "[heap]"; - goto done; - } - - if (vma_is_initial_stack(vma)) { - name = "[stack]"; - goto done; - } - - if (anon_name) { - seq_pad(m, ' '); - seq_printf(m, "[anon:%s]", anon_name->name); - } - } - -done: - if (name) { + seq_path(m, path, "\n"); + } else if (name_fmt) { + seq_pad(m, ' '); + seq_printf(m, name_fmt, name); + } else if (name) { seq_pad(m, ' '); seq_puts(m, name); } From patchwork Tue Jun 18 22:45:21 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrii Nakryiko X-Patchwork-Id: 13703111 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 CD3F8C27C4F for ; Tue, 18 Jun 2024 22:45:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E39686B0324; Tue, 18 Jun 2024 18:45:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DE9728D0066; Tue, 18 Jun 2024 18:45:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C64A76B0326; Tue, 18 Jun 2024 18:45:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id A0D5E6B0324 for ; Tue, 18 Jun 2024 18:45:41 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 5BB24A0BCD for ; Tue, 18 Jun 2024 22:45:41 +0000 (UTC) X-FDA: 82245492882.22.6A54309 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf08.hostedemail.com (Postfix) with ESMTP id A0112160005 for ; Tue, 18 Jun 2024 22:45:39 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=uClV9QVe; spf=pass (imf08.hostedemail.com: domain of andrii@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=andrii@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=1718750734; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=rtQB1609p1CjwcOqJMbb48isTvbVPy7O2Yj0W7R4odk=; b=o5oAfMscM6by3+A7jqLp/sUdQWz1cIBMqQVvNdRAyWQhN0QoQfGo/vP+1juI/lJUDuKQNE 1ZSmws3IyaEmWWGCy2kt/oZSI3GvUkotw87BzyiJTr7wHPZ0vvnnS2z+wKSGou0lhIMXv7 LE9EUKc8p6IECt2nz6dYlB9jNK2bPNU= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=uClV9QVe; spf=pass (imf08.hostedemail.com: domain of andrii@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=andrii@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718750734; a=rsa-sha256; cv=none; b=yy6potxQYuBBbt23GZdug1xuQAUd4yCdRPQ3Tdc6xjTfOx2zKYKWKHliBc+ikHwZerlqfy UZYK9V8dCkdhe2bFzWdh7BgsMXuXyeIua/D7y3a2Dxiejrau0pmgJaWs8Vqnp0RVhgm7Gb Bbbsx/TQI8+VRC87QSow2+c59nimICc= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id CCDA961B95; Tue, 18 Jun 2024 22:45:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 23272C32786; Tue, 18 Jun 2024 22:45:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1718750738; bh=dujWXwBtdE1rUgXOPw7cuUswvyKsdGxgOw5pbZroWtk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uClV9QVeqnWs3Bvp1YQVpJiEOwnBjkTjImCIVhbKbmNGl4MICEixB+BMjnNEUYjeu 0ZuY7rDytNBjBK5JJ3nzZLVtnZaffzw24RtsuOznpeo3l4kikYoaV5IawT870YNLS6 sZBj87OSATkFTJaco2ClArz+uojvXV035RWUVK1hExQT4M43rkFt+6Vms0KZNODsxR W9yJ+mBvPaZO5GDLhubo/dPWuzVKBzoceiHfD19R6zxxX0HkiKYe1YoVVaa3SiCQtV UMHntcOluo1rJb4SY+Hjht9CHD8jK68mRwGvR7IPjvLu4G+QR+3OoI/JsapihLmOB4 Jul94qm+rvkpA== From: Andrii Nakryiko To: linux-fsdevel@vger.kernel.org, brauner@kernel.org, viro@zeniv.linux.org.uk, akpm@linux-foundation.org Cc: 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, Andrii Nakryiko Subject: [PATCH v5 2/6] fs/procfs: implement efficient VMA querying API for /proc//maps Date: Tue, 18 Jun 2024 15:45:21 -0700 Message-ID: <20240618224527.3685213-3-andrii@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240618224527.3685213-1-andrii@kernel.org> References: <20240618224527.3685213-1-andrii@kernel.org> MIME-Version: 1.0 X-Stat-Signature: drfmag8uk1ssd9swobapw383g1hubaeu X-Rspam-User: X-Rspamd-Queue-Id: A0112160005 X-Rspamd-Server: rspam02 X-HE-Tag: 1718750739-511251 X-HE-Meta: U2FsdGVkX1/KFhfpVyIjQuI1U0sNvuqJeMYHXJsi0lANUnU89sy+4CX5EHM9Zw10JdNdvqmsRU2vla/EADE0OG9IG278AnWFqFPyJapXmNS1/yTApe93X2U6RSV+XCZr/LfmTLf5yAgaJpdZ3tKlRiY0lXMHVsX3kaNOlsU18DMzBmRTuXuA5rpgcrbPUAY29nL8ZR8qBSNu7L1kcu2KXrJnTbSY3oNozM/MLxMEy5JlOq+8Ha1nek1HwN+JgPqdUzrF8ImvqwI2J8ULe1NNrvFpL7mZcG9Ls5t/L5K6GJ01e7L9l+Xf2K7p5IC1hDPTFcb9rNCIO0IFTLVsUniOMl9SWtg97XRpFmxbVdJZyz9Crq4HrVnbe6yWOisdrh7Q/Y9jjWy7gPflh4ICLcyuoYBCacOU8uR4844S5uLBFUj3KjNgVgLZgzBfOawkQev+ZNV6CZVss2kkCqICKiNYvaJFzGGkTp7IZLnhEgpFsuEBp1d1OVXgTeTXS+7BuTuoNd3fk3zGNdzjgjQuU88ZgTwqIxHmre0zbD/1WI1MTlQowFwLLWsdDVwsDrvNWJk8n/ugESgSGUdfHWQRmUKq186I17tq0+5pVTG25qsNc+4Wk/83+sL6XdwEG6gDm6MRAw8sWhGsB0RlLOfGkQpl3oN4zNIFp+DKL4iRlKqYse2qgfOiIleCLTf1LKF1ct4NYd0cxjtLElyE5QflqR+a8xlobLlcTwqerTBdBi3Kc6nDZJ6h2EGJuNmOFfuzjxtI0nmGdVy3JVocIWvq1DxyHZCvqM84Cm/VGtQtdirnLOiLgTaUJAwnhv2cVDAJh2EkBcXf5vTxv1GLbBESgdrIYWTvWAjhPwpwZ9jfQAVZfsC55b+kTUIZhoHosV6DPPXsIyvOlaVGJP11u5M+d6rfYp7rbgF+yJwXf66aTMNdc3heir7c3rGuzfR1KxxJ4Jp6feG7RkbgR1UVqZ+nYuH u8pwKb65 +VkEsWoNd2RNgB5hJUT04bLCRWR9zpAIrHecrS9eRNzWKhyMo2nLPwt8Ei73xNfF5yxwyv/FYr6MinR96mr5lneCPkkzSiSpjrTbWP1G4UBdAo85MWpOhnq7sTsDYVMUsGZ040SLUdkR0MK8BVRwn7Ky3iMCF/Km2r5gf1V2Z4plGE+Nslm3MBXWbqtqfloplqkg1/jozxJbw/sOHeI0vcj4b9sNLIfoV9NklEvdA2CWHGQY= 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: /proc//maps file is extremely useful in practice for various tasks involving figuring out process memory layout, what files are backing any given memory range, etc. One important class of applications that absolutely rely on this are profilers/stack symbolizers (perf tool being one of them). Patterns of use differ, but they generally would fall into two categories. In on-demand pattern, a profiler/symbolizer would normally capture stack trace containing absolute memory addresses of some functions, and would then use /proc//maps file to find corresponding backing ELF files (normally, only executable VMAs are of interest), file offsets within them, and then continue from there to get yet more information (ELF symbols, DWARF information) to get human-readable symbolic information. This pattern is used by Meta's fleet-wide profiler, as one example. In preprocessing pattern, application doesn't know the set of addresses of interest, so it has to fetch all relevant VMAs (again, probably only executable ones), store or cache them, then proceed with profiling and stack trace capture. Once done, it would do symbolization based on stored VMA information. This can happen at much later point in time. This patterns is used by perf tool, as an example. In either case, there are both performance and correctness requirement involved. This address to VMA information translation has to be done as efficiently as possible, but also not miss any VMA (especially in the case of loading/unloading shared libraries). In practice, correctness can't be guaranteed (due to process dying before VMA data can be captured, or shared library being unloaded, etc), but any effort to maximize the chance of finding the VMA is appreciated. Unfortunately, for all the /proc//maps file universality and usefulness, it doesn't fit the above use cases 100%. First, it's main purpose is to emit all VMAs sequentially, but in practice captured addresses would fall only into a smaller subset of all process' VMAs, mainly containing executable text. Yet, library would need to parse most or all of the contents to find needed VMAs, as there is no way to skip VMAs that are of no use. Efficient library can do the linear pass and it is still relatively efficient, but it's definitely an overhead that can be avoided, if there was a way to do more targeted querying of the relevant VMA information. Second, it's a text based interface, which makes its programmatic use from applications and libraries more cumbersome and inefficient due to the need to handle text parsing to get necessary pieces of information. The overhead is actually payed both by kernel, formatting originally binary VMA data into text, and then by user space application, parsing it back into binary data for further use. For the on-demand pattern of usage, described above, another problem when writing generic stack trace symbolization library is an unfortunate performance-vs-correctness tradeoff that needs to be made. Library has to make a decision to either cache parsed contents of /proc//maps (after initial processing) to service future requests (if application requests to symbolize another set of addresses (for the same process), captured at some later time, which is typical for periodic/continuous profiling cases) to avoid higher costs of re-parsing this file. Or it has to choose to cache the contents in memory to speed up future requests. In the former case, more memory is used for the cache and there is a risk of getting stale data if application loads or unloads shared libraries, or otherwise changed its set of VMAs somehow, e.g., through additional mmap() calls. In the latter case, it's the performance hit that comes from re-opening the file and re-parsing its contents all over again. This patch aims to solve this problem by providing a new API built on top of /proc//maps. It's meant to address both non-selectiveness and text nature of /proc//maps, by giving user more control of what sort of VMA(s) needs to be queried, and being binary-based interface eliminates the overhead of text formatting (on kernel side) and parsing (on user space side). It's also designed to be extensible and forward/backward compatible by including required struct size field, which user has to provide. We use established copy_struct_from_user() approach to handle extensibility. User has a choice to pick either getting VMA that covers provided address or -ENOENT if none is found (exact, least surprising, case). Or, with an extra query flag (PROCMAP_QUERY_COVERING_OR_NEXT_VMA), they can get either VMA that covers the address (if there is one), or the closest next VMA (i.e., VMA with the smallest vm_start > addr). The latter allows more efficient use, but, given it could be a surprising behavior, requires an explicit opt-in. There is another query flag that is useful for some use cases. PROCMAP_QUERY_FILE_BACKED_VMA instructs this API to only return file-backed VMAs. Combining this with PROCMAP_QUERY_COVERING_OR_NEXT_VMA makes it possible to efficiently iterate only file-backed VMAs of the process, which is what profilers/symbolizers are normally interested in. All the above querying flags can be combined with (also optional) set of desired VMA permissions flags. This allows to, for example, iterate only an executable subset of VMAs, which is what preprocessing pattern, used by perf tool, would benefit from, as the assumption is that captured stack traces would have addresses of executable code. This saves time by skipping non-executable VMAs altogether efficienty. All these querying flags (modifiers) are orthogonal and can be combined in a semantically meaningful and natural way. Basing this ioctl()-based API on top of /proc//maps's FD makes sense given it's querying the same set of VMA data. It's also benefitial because permission checks for /proc//maps is performed at open time once, and the actual data read of text contents of /proc//maps is done without further permission checks. We piggyback on this pattern with ioctl()-based API as well, as that's a desired property. Both for performance reasons, but also for security and flexibility reasons. Allowing application to open an FD for /proc/self/maps without any extra capabilities, and then passing it to some sort of profiling agent through Unix-domain socket, would allow such profiling agent to not require some of the capabilities that are otherwise expected when opening /proc//maps file for *another* process. This is a desirable property for some more restricted setups. This new ioctl-based implementation doesn't interfere with seq_file-based implementation of /proc//maps textual interface, and so could be used together or independently without paying any price for that. Note also, that fetching VMA name (e.g., backing file path, or special hard-coded or user-provided names) is optional just like build ID. If user sets vma_name_size to zero, kernel code won't attempt to retrieve it, saving resources. Earlier versions of this patch set were adding per-VMA locking, which is why we have a code structure that is ready for abstracting mmap_lock vs vm_lock differences (query_vma_setup(), query_vma_teardown(), and query_vma_find_by_addr()), but given anon_vma_name() is not yet compatible with per-VMA locking, initial implementation sticks to using only mmap_lock for now. It will be easy to add back per-VMA locking once all the pieces are ready later on. Which is why we keep existing code structure with setup/teardown/query helper functions. Signed-off-by: Andrii Nakryiko --- fs/proc/task_mmu.c | 235 ++++++++++++++++++++++++++++++++++++++++ include/uapi/linux/fs.h | 130 +++++++++++++++++++++- 2 files changed, 364 insertions(+), 1 deletion(-) diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index 507b7dc7c4c8..674405b99d0d 100644 --- a/fs/proc/task_mmu.c +++ b/fs/proc/task_mmu.c @@ -375,11 +375,246 @@ static int pid_maps_open(struct inode *inode, struct file *file) return do_maps_open(inode, file, &proc_pid_maps_op); } +#define PROCMAP_QUERY_VMA_FLAGS ( \ + PROCMAP_QUERY_VMA_READABLE | \ + PROCMAP_QUERY_VMA_WRITABLE | \ + PROCMAP_QUERY_VMA_EXECUTABLE | \ + PROCMAP_QUERY_VMA_SHARED \ +) + +#define PROCMAP_QUERY_VALID_FLAGS_MASK ( \ + PROCMAP_QUERY_COVERING_OR_NEXT_VMA | \ + PROCMAP_QUERY_FILE_BACKED_VMA | \ + PROCMAP_QUERY_VMA_FLAGS \ +) + +static int query_vma_setup(struct mm_struct *mm) +{ + return mmap_read_lock_killable(mm); +} + +static void query_vma_teardown(struct mm_struct *mm, struct vm_area_struct *vma) +{ + mmap_read_unlock(mm); +} + +static struct vm_area_struct *query_vma_find_by_addr(struct mm_struct *mm, unsigned long addr) +{ + return find_vma(mm, addr); +} + +static struct vm_area_struct *query_matching_vma(struct mm_struct *mm, + unsigned long addr, u32 flags) +{ + struct vm_area_struct *vma; + +next_vma: + vma = query_vma_find_by_addr(mm, addr); + if (!vma) + goto no_vma; + + /* user requested only file-backed VMA, keep iterating */ + if ((flags & PROCMAP_QUERY_FILE_BACKED_VMA) && !vma->vm_file) + goto skip_vma; + + /* VMA permissions should satisfy query flags */ + if (flags & PROCMAP_QUERY_VMA_FLAGS) { + u32 perm = 0; + + if (flags & PROCMAP_QUERY_VMA_READABLE) + perm |= VM_READ; + if (flags & PROCMAP_QUERY_VMA_WRITABLE) + perm |= VM_WRITE; + if (flags & PROCMAP_QUERY_VMA_EXECUTABLE) + perm |= VM_EXEC; + if (flags & PROCMAP_QUERY_VMA_SHARED) + perm |= VM_MAYSHARE; + + if ((vma->vm_flags & perm) != perm) + goto skip_vma; + } + + /* found covering VMA or user is OK with the matching next VMA */ + if ((flags & PROCMAP_QUERY_COVERING_OR_NEXT_VMA) || vma->vm_start <= addr) + return vma; + +skip_vma: + /* + * If the user needs closest matching VMA, keep iterating. + */ + addr = vma->vm_end; + if (flags & PROCMAP_QUERY_COVERING_OR_NEXT_VMA) + goto next_vma; +no_vma: + return ERR_PTR(-ENOENT); +} + +static int do_procmap_query(struct proc_maps_private *priv, void __user *uarg) +{ + struct procmap_query karg; + struct vm_area_struct *vma; + struct mm_struct *mm; + const char *name = NULL; + char *name_buf = NULL; + __u64 usize; + int err; + + if (copy_from_user(&usize, (void __user *)uarg, sizeof(usize))) + return -EFAULT; + /* argument struct can never be that large, reject abuse */ + if (usize > PAGE_SIZE) + return -E2BIG; + /* argument struct should have at least query_flags and query_addr fields */ + if (usize < offsetofend(struct procmap_query, query_addr)) + return -EINVAL; + err = copy_struct_from_user(&karg, sizeof(karg), uarg, usize); + if (err) + return err; + + /* reject unknown flags */ + if (karg.query_flags & ~PROCMAP_QUERY_VALID_FLAGS_MASK) + return -EINVAL; + /* either both buffer address and size are set, or both should be zero */ + if (!!karg.vma_name_size != !!karg.vma_name_addr) + return -EINVAL; + + mm = priv->mm; + if (!mm || !mmget_not_zero(mm)) + return -ESRCH; + + err = query_vma_setup(mm); + if (err) { + mmput(mm); + return err; + } + + vma = query_matching_vma(mm, karg.query_addr, karg.query_flags); + if (IS_ERR(vma)) { + err = PTR_ERR(vma); + vma = NULL; + goto out; + } + + karg.vma_start = vma->vm_start; + karg.vma_end = vma->vm_end; + + karg.vma_flags = 0; + if (vma->vm_flags & VM_READ) + karg.vma_flags |= PROCMAP_QUERY_VMA_READABLE; + if (vma->vm_flags & VM_WRITE) + karg.vma_flags |= PROCMAP_QUERY_VMA_WRITABLE; + if (vma->vm_flags & VM_EXEC) + karg.vma_flags |= PROCMAP_QUERY_VMA_EXECUTABLE; + if (vma->vm_flags & VM_MAYSHARE) + karg.vma_flags |= PROCMAP_QUERY_VMA_SHARED; + + karg.vma_page_size = vma_kernel_pagesize(vma); + + if (vma->vm_file) { + const struct inode *inode = file_user_inode(vma->vm_file); + + karg.vma_offset = ((__u64)vma->vm_pgoff) << PAGE_SHIFT; + karg.dev_major = MAJOR(inode->i_sb->s_dev); + karg.dev_minor = MINOR(inode->i_sb->s_dev); + karg.inode = inode->i_ino; + } else { + karg.vma_offset = 0; + karg.dev_major = 0; + karg.dev_minor = 0; + karg.inode = 0; + } + + if (karg.build_id_size) { + __u32 build_id_sz; + + err = build_id_parse(vma, build_id_buf, &build_id_sz); + if (err) { + karg.build_id_size = 0; + } else { + if (karg.build_id_size < build_id_sz) { + err = -ENAMETOOLONG; + goto out; + } + karg.build_id_size = build_id_sz; + } + } + + if (karg.vma_name_size) { + size_t name_buf_sz = min_t(size_t, PATH_MAX, karg.vma_name_size); + const struct path *path; + const char *name_fmt; + size_t name_sz = 0; + + get_vma_name(vma, &path, &name, &name_fmt); + + if (path || name_fmt || name) { + name_buf = kmalloc(name_buf_sz, GFP_KERNEL); + if (!name_buf) { + err = -ENOMEM; + goto out; + } + } + if (path) { + name = d_path(path, name_buf, name_buf_sz); + if (IS_ERR(name)) { + err = PTR_ERR(name); + goto out; + } + name_sz = name_buf + name_buf_sz - name; + } else if (name || name_fmt) { + name_sz = 1 + snprintf(name_buf, name_buf_sz, name_fmt ?: "%s", name); + name = name_buf; + } + if (name_sz > name_buf_sz) { + err = -ENAMETOOLONG; + goto out; + } + karg.vma_name_size = name_sz; + } + + /* unlock vma or mmap_lock, and put mm_struct before copying data to user */ + query_vma_teardown(mm, vma); + mmput(mm); + + if (karg.vma_name_size && copy_to_user((void __user *)karg.vma_name_addr, + name, karg.vma_name_size)) { + kfree(name_buf); + return -EFAULT; + } + kfree(name_buf); + + if (copy_to_user(uarg, &karg, min_t(size_t, sizeof(karg), usize))) + return -EFAULT; + + return 0; + +out: + query_vma_teardown(mm, vma); + mmput(mm); + kfree(name_buf); + return err; +} + +static long procfs_procmap_ioctl(struct file *file, unsigned int cmd, unsigned long arg) +{ + struct seq_file *seq = file->private_data; + struct proc_maps_private *priv = seq->private; + + switch (cmd) { + case PROCMAP_QUERY: + return do_procmap_query(priv, (void __user *)arg); + default: + return -ENOIOCTLCMD; + } +} + const struct file_operations proc_pid_maps_operations = { .open = pid_maps_open, .read = seq_read, .llseek = seq_lseek, .release = proc_map_release, + .unlocked_ioctl = procfs_procmap_ioctl, + .compat_ioctl = procfs_procmap_ioctl, }; /* diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h index 45e4e64fd664..74480ed4fa78 100644 --- a/include/uapi/linux/fs.h +++ b/include/uapi/linux/fs.h @@ -333,8 +333,10 @@ typedef int __bitwise __kernel_rwf_t; #define RWF_SUPPORTED (RWF_HIPRI | RWF_DSYNC | RWF_SYNC | RWF_NOWAIT |\ RWF_APPEND | RWF_NOAPPEND) +#define PROCFS_IOCTL_MAGIC 'f' + /* Pagemap ioctl */ -#define PAGEMAP_SCAN _IOWR('f', 16, struct pm_scan_arg) +#define PAGEMAP_SCAN _IOWR(PROCFS_IOCTL_MAGIC, 16, struct pm_scan_arg) /* Bitmasks provided in pm_scan_args masks and reported in page_region.categories. */ #define PAGE_IS_WPALLOWED (1 << 0) @@ -393,4 +395,130 @@ struct pm_scan_arg { __u64 return_mask; }; +/* /proc//maps ioctl */ +#define PROCMAP_QUERY _IOWR(PROCFS_IOCTL_MAGIC, 17, struct procmap_query) + +enum procmap_query_flags { + /* + * VMA permission flags. + * + * Can be used as part of procmap_query.query_flags field to look up + * only VMAs satisfying specified subset of permissions. E.g., specifying + * PROCMAP_QUERY_VMA_READABLE only will return both readable and read/write VMAs, + * while having PROCMAP_QUERY_VMA_READABLE | PROCMAP_QUERY_VMA_WRITABLE will only + * return read/write VMAs, though both executable/non-executable and + * private/shared will be ignored. + * + * PROCMAP_QUERY_VMA_* flags are also returned in procmap_query.vma_flags + * field to specify actual VMA permissions. + */ + PROCMAP_QUERY_VMA_READABLE = 0x01, + PROCMAP_QUERY_VMA_WRITABLE = 0x02, + PROCMAP_QUERY_VMA_EXECUTABLE = 0x04, + PROCMAP_QUERY_VMA_SHARED = 0x08, + /* + * Query modifier flags. + * + * By default VMA that covers provided address is returned, or -ENOENT + * is returned. With PROCMAP_QUERY_COVERING_OR_NEXT_VMA flag set, closest + * VMA with vma_start > addr will be returned if no covering VMA is + * found. + * + * PROCMAP_QUERY_FILE_BACKED_VMA instructs query to consider only VMAs that + * have file backing. Can be combined with PROCMAP_QUERY_COVERING_OR_NEXT_VMA + * to iterate all VMAs with file backing. + */ + PROCMAP_QUERY_COVERING_OR_NEXT_VMA = 0x10, + PROCMAP_QUERY_FILE_BACKED_VMA = 0x20, +}; + +/* + * Input/output argument structured passed into ioctl() call. It can be used + * to query a set of VMAs (Virtual Memory Areas) of a process. + * + * Each field can be one of three kinds, marked in a short comment to the + * right of the field: + * - "in", input argument, user has to provide this value, kernel doesn't modify it; + * - "out", output argument, kernel sets this field with VMA data; + * - "in/out", input and output argument; user provides initial value (used + * to specify maximum allowable buffer size), and kernel sets it to actual + * amount of data written (or zero, if there is no data). + * + * If matching VMA is found (according to criterias specified by + * query_addr/query_flags, all the out fields are filled out, and ioctl() + * returns 0. If there is no matching VMA, -ENOENT will be returned. + * In case of any other error, negative error code other than -ENOENT is + * returned. + * + * Most of the data is similar to the one returned as text in /proc//maps + * file, but procmap_query provides more querying flexibility. There are no + * consistency guarantees between subsequent ioctl() calls, but data returned + * for matched VMA is self-consistent. + */ +struct procmap_query { + /* Query struct size, for backwards/forward compatibility */ + __u64 size; + /* + * Query flags, a combination of enum procmap_query_flags values. + * Defines query filtering and behavior, see enum procmap_query_flags. + * + * Input argument, provided by user. Kernel doesn't modify it. + */ + __u64 query_flags; /* in */ + /* + * Query address. By default, VMA that covers this address will + * be looked up. PROCMAP_QUERY_* flags above modify this default + * behavior further. + * + * Input argument, provided by user. Kernel doesn't modify it. + */ + __u64 query_addr; /* in */ + /* VMA starting (inclusive) and ending (exclusive) address, if VMA is found. */ + __u64 vma_start; /* out */ + __u64 vma_end; /* out */ + /* VMA permissions flags. A combination of PROCMAP_QUERY_VMA_* flags. */ + __u64 vma_flags; /* out */ + /* VMA backing page size granularity. */ + __u32 vma_page_size; /* out */ + /* + * VMA file offset. If VMA has file backing, this specifies offset + * within the file that VMA's start address corresponds to. + * Is set to zero if VMA has no backing file. + */ + __u64 vma_offset; /* out */ + /* Backing file's inode number, or zero, if VMA has no backing file. */ + __u64 inode; /* out */ + /* Backing file's device major/minor number, or zero, if VMA has no backing file. */ + __u32 dev_major; /* out */ + __u32 dev_minor; /* out */ + /* + * If set to non-zero value, signals the request to return VMA name + * (i.e., VMA's backing file's absolute path, with " (deleted)" suffix + * appended, if file was unlinked from FS) for matched VMA. VMA name + * can also be some special name (e.g., "[heap]", "[stack]") or could + * be even user-supplied with prctl(PR_SET_VMA, PR_SET_VMA_ANON_NAME). + * + * Kernel will set this field to zero, if VMA has no associated name. + * Otherwise kernel will return actual amount of bytes filled in + * user-supplied buffer (see vma_name_addr field below), including the + * terminating zero. + * + * If VMA name is longer that user-supplied maximum buffer size, + * -E2BIG error is returned. + * + * If this field is set to non-zero value, vma_name_addr should point + * to valid user space memory buffer of at least vma_name_size bytes. + * If set to zero, vma_name_addr should be set to zero as well + */ + __u32 vma_name_size; /* in/out */ + /* + * User-supplied address of a buffer of at least vma_name_size bytes + * for kernel to fill with matched VMA's name (see vma_name_size field + * description above for details). + * + * Should be set to zero if VMA name should not be returned. + */ + __u64 vma_name_addr; /* in */ +}; + #endif /* _UAPI_LINUX_FS_H */ From patchwork Tue Jun 18 22:45:22 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrii Nakryiko X-Patchwork-Id: 13703113 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 CF38AC2BA15 for ; Tue, 18 Jun 2024 22:45:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 27E516B034A; Tue, 18 Jun 2024 18:45:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 22B8F6B034C; Tue, 18 Jun 2024 18:45:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0A51B6B034D; Tue, 18 Jun 2024 18:45:45 -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 D7BD86B034A for ; Tue, 18 Jun 2024 18:45:44 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 838AD80B53 for ; Tue, 18 Jun 2024 22:45:44 +0000 (UTC) X-FDA: 82245493008.23.246EE8B Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf13.hostedemail.com (Postfix) with ESMTP id B7EBA20004 for ; Tue, 18 Jun 2024 22:45:42 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=PCC94icD; spf=pass (imf13.hostedemail.com: domain of andrii@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=andrii@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=1718750735; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=yb3fOI9iH5eScAcpMLdfW7BGqwyPH0JwVH9B2m1DQEA=; b=qe1QOq2eR32W2gCvnjJYWylv1UryyO90pQlzsms3sLEeEdvM0Zw4AANQw2x19FGEu2Bjyj GYIx53SYLJZ/1P2m0vhsYb6x0KVsNodPDnxITFVWsyoLzLDfbTHT9vTpguGV29XyVCAtTu sskp+foe8jHlk19Fs78CTK9GWx3zFKY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718750735; a=rsa-sha256; cv=none; b=sp89KvAgL/Rvb1mtcA9rPgIcQ3M/WZUU2KWpvbjIa2G1WRXPamYnbGAvLVBXCNrqDpYtYR sOA7MN/EzFqFj7D+xosBtCytuzoI539SfV5dt7BqeVacyn5NXUMHYQbqFbFLt7zu88Itxs kvkDZ4iSWde7ZJ1ZORICk0JQ5w6OhH8= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=PCC94icD; spf=pass (imf13.hostedemail.com: domain of andrii@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=andrii@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id D3D7361B7D; Tue, 18 Jun 2024 22:45:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 79578C3277B; Tue, 18 Jun 2024 22:45:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1718750741; bh=oHyCroq8ofe3DxAkUhI+3vlruUfjDuTglHhZ9P5zO/Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PCC94icDGrN6b6JhjYQb7+q9Kg8f9qhUjkAs3sZmXuJRY2iPs+oZZysUPeh6+FECY Zt1U/mCzLd5GNKxbHk4LaOw63kcbemny5RUAnZEO+hP5fvI7DNQSUxIbmCJY0ZISsm 3iX5fdMvI2xE+8Z+dor5LL41BdhbwZtBrrvaxw00BgUJSzFyZLsIWBUi2vxKQR5iIn U8Efft3IRmhUNLoekTM27t87xrLq8rSdU8yuOwhRBPz32jOo3WNpF4XcxQQN9ZT4RJ fu9XY7JcOkKEPk5rfzbglurocMh22TKqphvUU037hwl//FtF93IzQ9tDuEjKf/I9iC BoHG4kNmHyaUQ== From: Andrii Nakryiko To: linux-fsdevel@vger.kernel.org, brauner@kernel.org, viro@zeniv.linux.org.uk, akpm@linux-foundation.org Cc: 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, Andrii Nakryiko Subject: [PATCH v5 3/6] fs/procfs: add build ID fetching to PROCMAP_QUERY API Date: Tue, 18 Jun 2024 15:45:22 -0700 Message-ID: <20240618224527.3685213-4-andrii@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240618224527.3685213-1-andrii@kernel.org> References: <20240618224527.3685213-1-andrii@kernel.org> MIME-Version: 1.0 X-Stat-Signature: 789hizni4eugzu5niabqfjis998xix8a X-Rspamd-Queue-Id: B7EBA20004 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1718750742-597933 X-HE-Meta: U2FsdGVkX1+PVkF0PspQZMc/5Ix3/z3Hvw7Oc7L4EwE8Xn05VM+gJv/i+YzP7Jv7tRKY4BYOt2g4lrzFEoXjK6GngC/eXICrFiOi2BEv5X+sanpDdBfmOPqDCNqYRxfgCZWeoe0fsQcToRPRBHXPVlmZ4Itg9RpV+ZbqD9pwE1Urdt0gpZ8D4hlOAdU/5+Oi3Dqjc6P2M77LhlaizjK2vyJgzurFbSqn4T1t/XCO2e8xah3FEz3F5bmFhAjTFhHBHERBM/uun/+JbH0QdPojAbkHzIqDF1b2E8gL9uwwGz0xaZnRorYz5vuk0s5Y7iUnWlBRbeosudLWV9POl3OW5oFe+lWVOt9uKW6kXM6PTk3t9SfzanmEbQqq6Qj3gmaB+UNb24ZplGiL3tcPppRL3mV27A/jyUv5DyJPE2HcA7L4O4wYcj/+khzFLGqIAE61+t04qrwvnS4hmf2bczFRjdrncVKB1kGVxaB5er6FckuU3+cKrc78MAH0U/2KOYI8/yvPX/hodrFovh/zbG+kWrdCg2dSiV2i9J/IYb6tbC2t7vmuyN7vpiIRoITcclU96aloKEW6Wm2wnWWWDlLLdzr3oTmoCKJ0X7JYmdkJ4iC6tL+j+qItvtNNHz0WytUwiw5MSFcBH08W/G6MJb6hR0oaPvC8PR5ciiDtA9lnvsPuGBHhw5u0Ndds3ZCezTXnw4Mrhio+t9PrX/ZrwnUHv6qQQJTumY5JOp5q1x5OofELMz0oUAo8YVBcX+dkOs0GvMzuvNTRPhEQvYeaAkg18/cNzGy2JGJuYQu7aiGypz8AU5g2HypbqFpU1Xsh4BPyBcc5fxl332Ngn2hCD5YwVhNi9Tfi/Q7VvXhic9gfh+XUfJ0RZtNQlQ1yaLx2ZFmmUXGgpRlvhE+3rVosPOexKLKCWVDGenSfvR/EtN6heiWpT6JIpZ6hJo/0WsPo38a4MMfPkVQoIvE2Nnvl9f7 /hS+ZptH jwqrm95qEIYDag7aFzjwTFMimrAPBLcyBYSfzgblGefjTBI7oWxeh449qKkZjYB1saM9g7MWsqXIjRRlGh/unNaKPp5E+Cx0pPtZiy3D95y7wk+22H3VsCt++YAk7T432uv/Z1z4vHfFaxc7WvquKoVjkJbnjJGfBKVGNHilviVRwUlHWetMYxsxpUemvjk1lEaZpI6IHOavslGlyBMsElhd+MLjx8oZ/TfZYiO7uVvNW1Qgohfe9BrRP3N+vt2atH+Qnt56f8MK5usdw4jkVkaoqLpKlIycTIBTr 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: 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. To get backing file's ELF build ID, application has to first resolve VMA, then use it's start/end address range to follow a special /proc//map_files/- symlink to open the ELF file (this is necessary because backing file might have been removed from the disk or was already replaced with another binary in the same file path. Such approach, beyond just adding complexity of having to do a bunch of extra work, has extra security implications. Because application opens underlying ELF file and needs read access to its entire contents (as far as kernel is concerned), kernel puts additional capable() checks on following /proc//map_files/- symlink. And that makes sense in general. But in the case of build ID, profiler/symbolizer doesn't need the contents of ELF file, per se. It's only build ID that is of interest, and ELF build ID itself doesn't provide any sensitive information. So this patch adds a way to request backing file's ELF build ID along the rest of VMA information in the same API. User has control over whether this piece of information is requested or not by either setting build_id_size field to zero or non-zero maximum buffer size they provided through build_id_addr field (which encodes user pointer as __u64 field). This is a completely optional piece of information, and so has no performance implications for user cases that don't care about build ID, while improving performance and simplifying the setup for those application that do need it. Kernel already implements build ID fetching, which is used from BPF subsystem. We are reusing this code here, but plan a follow up changes to make it work better under more relaxed assumption (compared to what existing code assumes) of being called from user process context, in which page faults are allowed. BPF-specific implementation currently bails out if necessary part of ELF file is not paged in, all due to extra BPF-specific restrictions (like the need to fetch build ID in restrictive contexts such as NMI handler). Signed-off-by: Andrii Nakryiko --- fs/proc/task_mmu.c | 25 ++++++++++++++++++++++++- include/uapi/linux/fs.h | 28 ++++++++++++++++++++++++++++ 2 files changed, 52 insertions(+), 1 deletion(-) diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index 674405b99d0d..32bef3eeab7f 100644 --- a/fs/proc/task_mmu.c +++ b/fs/proc/task_mmu.c @@ -22,6 +22,7 @@ #include #include #include +#include #include #include @@ -445,6 +446,7 @@ static struct vm_area_struct *query_matching_vma(struct mm_struct *mm, addr = vma->vm_end; if (flags & PROCMAP_QUERY_COVERING_OR_NEXT_VMA) goto next_vma; + no_vma: return ERR_PTR(-ENOENT); } @@ -455,7 +457,7 @@ static int do_procmap_query(struct proc_maps_private *priv, void __user *uarg) struct vm_area_struct *vma; struct mm_struct *mm; const char *name = NULL; - char *name_buf = NULL; + char build_id_buf[BUILD_ID_SIZE_MAX], *name_buf = NULL; __u64 usize; int err; @@ -477,6 +479,8 @@ static int do_procmap_query(struct proc_maps_private *priv, void __user *uarg) /* either both buffer address and size are set, or both should be zero */ if (!!karg.vma_name_size != !!karg.vma_name_addr) return -EINVAL; + if (!!karg.build_id_size != !!karg.build_id_addr) + return -EINVAL; mm = priv->mm; if (!mm || !mmget_not_zero(mm)) @@ -539,6 +543,21 @@ static int do_procmap_query(struct proc_maps_private *priv, void __user *uarg) } } + if (karg.build_id_size) { + __u32 build_id_sz; + + err = build_id_parse(vma, build_id_buf, &build_id_sz); + if (err) { + karg.build_id_size = 0; + } else { + if (karg.build_id_size < build_id_sz) { + err = -ENAMETOOLONG; + goto out; + } + karg.build_id_size = build_id_sz; + } + } + if (karg.vma_name_size) { size_t name_buf_sz = min_t(size_t, PATH_MAX, karg.vma_name_size); const struct path *path; @@ -583,6 +602,10 @@ static int do_procmap_query(struct proc_maps_private *priv, void __user *uarg) } kfree(name_buf); + if (karg.build_id_size && copy_to_user((void __user *)karg.build_id_addr, + build_id_buf, karg.build_id_size)) + return -EFAULT; + if (copy_to_user(uarg, &karg, min_t(size_t, sizeof(karg), usize))) return -EFAULT; diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h index 74480ed4fa78..cad6375044bc 100644 --- a/include/uapi/linux/fs.h +++ b/include/uapi/linux/fs.h @@ -511,6 +511,26 @@ struct procmap_query { * If set to zero, vma_name_addr should be set to zero as well */ __u32 vma_name_size; /* in/out */ + /* + * If set to non-zero value, signals the request to extract and return + * VMA's backing file's build ID, if the backing file is an ELF file + * and it contains embedded build ID. + * + * Kernel will set this field to zero, if VMA has no backing file, + * backing file is not an ELF file, or ELF file has no build ID + * embedded. + * + * Build ID is a binary value (not a string). Kernel will set + * build_id_size field to exact number of bytes used for build ID. + * If build ID is requested and present, but needs more bytes than + * user-supplied maximum buffer size (see build_id_addr field below), + * -E2BIG error will be returned. + * + * If this field is set to non-zero value, build_id_addr should point + * to valid user space memory buffer of at least build_id_size bytes. + * 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 bytes * 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 bytes + * for kernel to fill with matched VMA's ELF build ID, if available + * (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 */ }; #endif /* _UAPI_LINUX_FS_H */ From patchwork Tue Jun 18 22:45:23 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrii Nakryiko X-Patchwork-Id: 13703114 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 C184FC27C4F for ; Tue, 18 Jun 2024 22:45:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3B4738D006D; Tue, 18 Jun 2024 18:45:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3620D8D0066; Tue, 18 Jun 2024 18:45:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 205448D006D; Tue, 18 Jun 2024 18:45:51 -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 F33CB8D0066 for ; Tue, 18 Jun 2024 18:45:50 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id A40561C18E9 for ; Tue, 18 Jun 2024 22:45:50 +0000 (UTC) X-FDA: 82245493260.28.C5E7114 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf16.hostedemail.com (Postfix) with ESMTP id 99C38180009 for ; Tue, 18 Jun 2024 22:45:48 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=U6biJYZj; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf16.hostedemail.com: domain of andrii@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=andrii@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718750741; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Nqqeguxhnv70YJ/Hlnzz44ng4fnExjdR7VvZFZgjwVY=; b=8VZ9et5/zuCyeg1t48KCtMemovW/aroDgZ/s42RgmHV2NkB+Sm7f+XAsX9In7amcjV6cut DvBTkUzd3QlLWC+uHFHRFOpR64dIAYPxpI25fG5ZHQmbsgZW47UvyTHulKgJUY4FLoOE4q 9QVCJdzSJbXu19RMqGRbdM1IEYoRFCM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718750741; a=rsa-sha256; cv=none; b=sEhLDKrJqFSv8TCOa5bmK8JyCb+Zzm8RDTRsR21QC4eiN/JWoHc5wHB0lfKjXtbm1bO5kK 0ck51G5DwecjDZeO5UuB8yXmyr7g4ytl6j4yUFl3ZyYShU7LTAnTxHEAkfdqprZavbaARU dqMj4T9YU+kcXAO120w37UQDb5cvG4A= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=U6biJYZj; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf16.hostedemail.com: domain of andrii@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=andrii@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 98AB5CE1C43; Tue, 18 Jun 2024 22:45:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C2380C3277B; Tue, 18 Jun 2024 22:45:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1718750744; bh=OCMwDvtwnM9ll0Ws/wHw8cfOMgOXkr3TtaYN7UcD3wM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=U6biJYZjx6n/yCnySOnJ/0QKNa/AdfaW7t0ofQIiqUjfxQORpwwEtMKkdom44OrDp ciJqfeQLQp6xpBxzairrodBgPeEdKbthUWTC8mOpCqWJXZIF1lkgS2Ovcb3HSouGco odzJtA+I/GY+BTi2k8Y975PSowJFGg+RJyoAZx+D+HkVHKxap3ozWJnwi5/UUSeTK8 wgYNclpkinStLKlNAmuF0/30bdegIQUmot8p/2thA1xiyHoEpypV8AzoW/DX/tAH4D Qd/1lXbdNvu30g67If6EG6mqTC++NuB0wG/3mkRolc5ow+dFDtDH3pculy5/ICg6vq a253IBmOo5Dtg== From: Andrii Nakryiko To: linux-fsdevel@vger.kernel.org, brauner@kernel.org, viro@zeniv.linux.org.uk, akpm@linux-foundation.org Cc: 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, Andrii Nakryiko Subject: [PATCH v5 4/6] docs/procfs: call out ioctl()-based PROCMAP_QUERY command existence Date: Tue, 18 Jun 2024 15:45:23 -0700 Message-ID: <20240618224527.3685213-5-andrii@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240618224527.3685213-1-andrii@kernel.org> References: <20240618224527.3685213-1-andrii@kernel.org> MIME-Version: 1.0 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 99C38180009 X-Stat-Signature: 897wzkiz75o4tzchzsdzyjgybcuisca3 X-Rspam-User: X-HE-Tag: 1718750748-707691 X-HE-Meta: U2FsdGVkX1+xVbhL0jGbHdcQTbIzgmXBcpA37NctNX5WlYAvOFNaw8b75HOJ1H/OK+D5LQIiHnvD1WRKnNIv1Oh0tsqXkzq7+17c7Tuly8v6J6y+NTqK2OwT/znE1i3ZxMDx2jVmWa61+6GA+95GXH88LR8dNQt4ebl3Av/i+3Hdrll0hkv/Y6i4F9LaOSwTiFlgSx1g6OusXJ6+CehJc7LFsDx/hVwRRjBJIA/O2Z/BUUXyUUT7lNfDwtvyNaIzJXpYkdsRgy5fr+h7emhxiO33QN2rxfvYCSycjoA9l02l2cTg0P69wiY5OFpwZ+mZxJqfg9DHTBDLlmmF29SC2pCXPJs+lj42QrjH4Vh6O5iGe+eXcOiKrq9oSL39wCapRUkO/i6bp602bE7hdyHbd0Gi5ttxAZMFWhKMxPEvzEEgqDTHXcHMX1YfjNDD9+KHfU4Aa7xEfcUJZL9DaMSCK0yS3WK1AE+kYoY3qirMl9aIQxbssatIOOaJ2nGSzlTN1Ig3bLohKbuIcL2deaZdlQJ2bdzF8EBD74lb8F799cRTjn4QcTiYsvkKuVisF0XX/pPnYSF5E87Qgv9J9k4NQkvuCJofnqwKoKDKnT9lSHAwRjXRbrStLx0CLRyX7hs3uxFPysfcfqNj2Cgv01brIkQqKSaTemwdaEWG8vgw6dsodSn14Rgttt5CXM/6B6vXBfUuDB5MUGL8c5634T8B8+X8z2AbWPy72dNt1N0F+63l5NkFOqz8WP6PTXjUryUjqJYP8DQt63Knxqnz+ReMvbOzQq8jvHCgYyWPkjrcKOBv/CnoMEfBYwBt3G/aBZfVuG7AXR3X9A9BCG0hdBlpuMTVR5WjeG01j0CtLZOU0eRYwzYqhhUJTx1cGhSGlTfinnKZWEMz1d1OldUrvxZJ2SdI7jkXjsbTmFE2Pys/V3Kn1H9vlMyBVfouIhBfmG6NqvevW2T/iMeitAzUxnV gSF0MM0m 2pGhMgxYrijbIqDufR3mMF/X79xCLfYAgpbBgmkcFUL/t8GyJMxmecG845U0UqBirMq6L4ebvo4f76/a/ekBPXX22LmklsaV0sG7tUJV8gRdavggXJW9la4u3tVSBo/Yvq0gOaTE3zXmzRm6l1T6HyI/OJkCpEWbCaQKmhKROenr7BP7AC7uvdcMK8PbXp2IN+7iB+AUHGhDNTurx0klhWGgH70SwcJIaAXnUzkMNlaEWTwov3ZbNV+Cc6prL3OxMQcpuZMDyp3Z19XkoKIzhVYCXzD/cnLLaALQs 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: Call out PROCMAP_QUERY ioctl() existence in the section describing /proc/PID/maps file in documentation. We refer user to UAPI header for low-level details of this programmatic interface. Signed-off-by: Andrii Nakryiko --- Documentation/filesystems/proc.rst | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst index 82d142de3461..e834779d9611 100644 --- a/Documentation/filesystems/proc.rst +++ b/Documentation/filesystems/proc.rst @@ -443,6 +443,15 @@ is not associated with a file: or if empty, the mapping is anonymous. +Starting with 6.11 kernel, /proc/PID/maps provides an alternative +ioctl()-based API that gives ability to flexibly and efficiently query and +filter individual VMAs. This interface is binary and is meant for more +efficient and easy programmatic use. `struct procmap_query`, defined in +linux/fs.h UAPI header, serves as an input/output argument to the +`PROCMAP_QUERY` ioctl() command. See comments in linus/fs.h UAPI header for +details on query semantics, supported flags, data returned, and general API +usage information. + The /proc/PID/smaps is an extension based on maps, showing the memory consumption for each of the process's mappings. For each mapping (aka Virtual Memory Area, or VMA) there is a series of lines such as the following:: From patchwork Tue Jun 18 22:45:24 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrii Nakryiko X-Patchwork-Id: 13703115 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 D3E18C27C4F for ; Tue, 18 Jun 2024 22:45:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5AEDF8D006E; Tue, 18 Jun 2024 18:45:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5374C8D0066; Tue, 18 Jun 2024 18:45:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3627F8D006E; Tue, 18 Jun 2024 18:45:54 -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 137708D0066 for ; Tue, 18 Jun 2024 18:45:54 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id B7166A0ABF for ; Tue, 18 Jun 2024 22:45:53 +0000 (UTC) X-FDA: 82245493386.24.6457290 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf30.hostedemail.com (Postfix) with ESMTP id 6465F80014 for ; Tue, 18 Jun 2024 22:45:51 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=h+7m1+Mf; spf=pass (imf30.hostedemail.com: domain of andrii@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=andrii@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=1718750747; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=+BHFCISMLwJKW22QX58L7fMOjU5YYBLJsv1sprYhrVQ=; b=G9f7KgS8JKzs1Xw5m0o8mX8fvYdZjuZ6nqUz1ZjXQ/cr4L+cc65YYK6zXKiDmEmH+ghCKL NWsPTF34Wcs9s+TMXFG+X/AM4s5wUZnKWJVSgKFEa1AV3PKDuKORYOdgi9n9ThB11T7Ge/ TrHtbRsvTyFU1v6jodrhGKkdFxwNse8= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=h+7m1+Mf; spf=pass (imf30.hostedemail.com: domain of andrii@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=andrii@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718750747; a=rsa-sha256; cv=none; b=7ZtK30l6XYEW8pdKAsvS2mMgjESIBiqXPzeCtP6zUw4NgM0/GvzykcAUdgT2WoL6/3yAtV QNcnqjblW/bV74QNmGeb3Q6OkST7rqbBN+0Ee6rqNsDeA2U3BxjwPklBOTCQHEwGnCMxm6 OioNB+zX9PR4fGNXoIDpEAWcNMLyigE= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id D8BA5CE1BAC; Tue, 18 Jun 2024 22:45:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0592AC32786; Tue, 18 Jun 2024 22:45:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1718750748; bh=BRYHJjN55WzCmrelJcd8JVcPZniK31ZSH/3ppJflWBk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=h+7m1+MftxjtctKSgK+ErwiEiUuKyGqmCNL+qDMH6l5ecOdq7PogE8ZeY9/wQDkWz yaB4VZX+sao0OsXy2X3rmy+7mqsMauaYi9vEVXYvwzl1lOeK631bUfPUV5yIpH4dv+ Pg1sTWe842h1BzI3FOevUeMSseDIShK6pHN7HYXZenyQIJhcb+9jy67xmMOq81DPRH ElfNqsmCu/VRajWHgAkegR7UbM2In+9u6yIFvHXyO/ptL+oBlvujZbqJimkz6L2QLd JMaW5qvY4WeDV3opbnev60+toF+pj5/fzA13ywqOkNHJxp0yh7UnpYoEtJ3Bo2s9kr r4EdVfrIUNf/A== From: Andrii Nakryiko To: linux-fsdevel@vger.kernel.org, brauner@kernel.org, viro@zeniv.linux.org.uk, akpm@linux-foundation.org Cc: 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, Andrii Nakryiko Subject: [PATCH v5 5/6] tools: sync uapi/linux/fs.h header into tools subdir Date: Tue, 18 Jun 2024 15:45:24 -0700 Message-ID: <20240618224527.3685213-6-andrii@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240618224527.3685213-1-andrii@kernel.org> References: <20240618224527.3685213-1-andrii@kernel.org> MIME-Version: 1.0 X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 6465F80014 X-Stat-Signature: 88j33j7ta4ibogs77axfo9dig37ba4dr X-Rspam-User: X-HE-Tag: 1718750750-452663 X-HE-Meta: U2FsdGVkX1/JdgKbt5v0VCa8bJxOpmEbV0Bmr4LRSanQm7PJTOEuG10a+6lh1iPDMGnTfGx4E81+a7eOiHvdoJFYM4qa+q1TZieq9wGrWfmO+L17tlbvphrsw8zrkk8znp/SKYsEvCDKnqARojUwe/zCDl94pnuIdcs8F2S3d9zjhaqNrRYXfJmU3MmK9Nzqx/b6j49dGLE/dzBQO4zCqQJPmyzawpkemV5yuW7w/PyNEGqm3xl84SIDN1tU2KUP8441ffMNSSrUJtdQIwsaQpMQ8deYxcqJAYBMAsQ3CiBE3NxuRdQDIuKk4/lyd6yMxrLOFVBeFgSjFFPY3h4G7t+iSaPOImoB6oHo0igCqhbSWvtafUbd0KH3Qb1qePu6kvzyXLo9QtgqA6s8T7y+ZyuTAuyH7YQUoX3VVWV9waP7m8GBosS8vjA+dKvYu3sOTyKSBQdvvIz0uc6v/PhTxVegJWEBHWnDLaA9urFHanYXl8rDdNqYNIBJNWLtwCueTsy7Wu9/ZvwO/oFZqMdlBTGbo6uA521B9mDShbyvL05hFXlYrBQfnM8yFs+V7TWkU37kML1p7lFd7XWpOVatg+o1id1qXHFD/4+7SvB68INGx5Y9FLVsiIKTkfx8RMjnXjQF8LZTTFWXbwDIYDoszWWTweqEWXMM0RslDeQ4aIGq4gD7UdlGfTj/6y7Pj8KyXS9WNgwRIWs+bGtQBqBbNbDMp2w8IUn/YWZ2wyxdwC8WNce6CG/2hNTiHkgbcRvhtCzVTE50XhU8BM0sUXQmt+yLHLrRCek462/gNDRf1ZRAmUB2P56nNf1w6M+i/eKLxAD5Jj+7uMubeSZoSuoOj/aRzLVZi2I8QTwmwCYglzbEbK8SC27reZsFBAqfG5mn0e31YjEnkQZxt8j/nmzlUOOtdQ8PEMKC/d6gtC05WPAMKJHugrvIhJvUkvHIocytFw5Pga6RAl/fh19kNl5 sEfsxW2i iZxlMlhVVll0N0gcSSY178wqmbZdEs34EpwFD+YPR7sRhIBanph224x16PNJzj6YkVqelAqhdDonE8X6AZ/h/TlIxEBGN7RpDR/LaB6/7l/6kqFBYWFGPbLzdPD0lCDDO7gmWpWmJcGKAMyN7aWpXAs2HrXnKXsA+v1q9EFzQ+ZRejwVrH4hMpwCTFgtWluYnPWgZ741a8lcavEU3f/vDiCeZMqqYs+ABy1vVWpfHrho7lkY= 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: We need this UAPI header in tools/include subdirectory for using it from BPF selftests. Signed-off-by: Andrii Nakryiko --- tools/include/uapi/linux/fs.h | 184 +++++++++++++++++++++++++++++++--- 1 file changed, 172 insertions(+), 12 deletions(-) diff --git a/tools/include/uapi/linux/fs.h b/tools/include/uapi/linux/fs.h index cc3fea99fd43..cad6375044bc 100644 --- a/tools/include/uapi/linux/fs.h +++ b/tools/include/uapi/linux/fs.h @@ -1,6 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ -#ifndef _LINUX_FS_H -#define _LINUX_FS_H +#ifndef _UAPI_LINUX_FS_H +#define _UAPI_LINUX_FS_H /* * This file has definitions for some important file table structures @@ -13,10 +13,14 @@ #include #include #include +#ifndef __KERNEL__ #include +#endif /* Use of MS_* flags within the kernel is restricted to core mount(2) code. */ +#if !defined(__KERNEL__) #include +#endif /* * It's silly to have NR_OPEN bigger than NR_FILE, but you can change @@ -24,8 +28,8 @@ * nr_file rlimit, so it's safe to set up a ridiculously high absolute * upper limit on files-per-process. * - * Some programs (notably those using select()) may have to be - * recompiled to take full advantage of the new limits.. + * Some programs (notably those using select()) may have to be + * recompiled to take full advantage of the new limits.. */ /* Fixed constants first: */ @@ -308,29 +312,31 @@ struct fsxattr { typedef int __bitwise __kernel_rwf_t; /* high priority request, poll if possible */ -#define RWF_HIPRI ((__kernel_rwf_t)0x00000001) +#define RWF_HIPRI ((__force __kernel_rwf_t)0x00000001) /* per-IO O_DSYNC */ -#define RWF_DSYNC ((__kernel_rwf_t)0x00000002) +#define RWF_DSYNC ((__force __kernel_rwf_t)0x00000002) /* per-IO O_SYNC */ -#define RWF_SYNC ((__kernel_rwf_t)0x00000004) +#define RWF_SYNC ((__force __kernel_rwf_t)0x00000004) /* per-IO, return -EAGAIN if operation would block */ -#define RWF_NOWAIT ((__kernel_rwf_t)0x00000008) +#define RWF_NOWAIT ((__force __kernel_rwf_t)0x00000008) /* per-IO O_APPEND */ -#define RWF_APPEND ((__kernel_rwf_t)0x00000010) +#define RWF_APPEND ((__force __kernel_rwf_t)0x00000010) /* per-IO negation of O_APPEND */ -#define RWF_NOAPPEND ((__kernel_rwf_t)0x00000020) +#define RWF_NOAPPEND ((__force __kernel_rwf_t)0x00000020) /* mask of flags supported by the kernel */ #define RWF_SUPPORTED (RWF_HIPRI | RWF_DSYNC | RWF_SYNC | RWF_NOWAIT |\ RWF_APPEND | RWF_NOAPPEND) +#define PROCFS_IOCTL_MAGIC 'f' + /* Pagemap ioctl */ -#define PAGEMAP_SCAN _IOWR('f', 16, struct pm_scan_arg) +#define PAGEMAP_SCAN _IOWR(PROCFS_IOCTL_MAGIC, 16, struct pm_scan_arg) /* Bitmasks provided in pm_scan_args masks and reported in page_region.categories. */ #define PAGE_IS_WPALLOWED (1 << 0) @@ -389,4 +395,158 @@ struct pm_scan_arg { __u64 return_mask; }; -#endif /* _LINUX_FS_H */ +/* /proc//maps ioctl */ +#define PROCMAP_QUERY _IOWR(PROCFS_IOCTL_MAGIC, 17, struct procmap_query) + +enum procmap_query_flags { + /* + * VMA permission flags. + * + * Can be used as part of procmap_query.query_flags field to look up + * only VMAs satisfying specified subset of permissions. E.g., specifying + * PROCMAP_QUERY_VMA_READABLE only will return both readable and read/write VMAs, + * while having PROCMAP_QUERY_VMA_READABLE | PROCMAP_QUERY_VMA_WRITABLE will only + * return read/write VMAs, though both executable/non-executable and + * private/shared will be ignored. + * + * PROCMAP_QUERY_VMA_* flags are also returned in procmap_query.vma_flags + * field to specify actual VMA permissions. + */ + PROCMAP_QUERY_VMA_READABLE = 0x01, + PROCMAP_QUERY_VMA_WRITABLE = 0x02, + PROCMAP_QUERY_VMA_EXECUTABLE = 0x04, + PROCMAP_QUERY_VMA_SHARED = 0x08, + /* + * Query modifier flags. + * + * By default VMA that covers provided address is returned, or -ENOENT + * is returned. With PROCMAP_QUERY_COVERING_OR_NEXT_VMA flag set, closest + * VMA with vma_start > addr will be returned if no covering VMA is + * found. + * + * PROCMAP_QUERY_FILE_BACKED_VMA instructs query to consider only VMAs that + * have file backing. Can be combined with PROCMAP_QUERY_COVERING_OR_NEXT_VMA + * to iterate all VMAs with file backing. + */ + PROCMAP_QUERY_COVERING_OR_NEXT_VMA = 0x10, + PROCMAP_QUERY_FILE_BACKED_VMA = 0x20, +}; + +/* + * Input/output argument structured passed into ioctl() call. It can be used + * to query a set of VMAs (Virtual Memory Areas) of a process. + * + * Each field can be one of three kinds, marked in a short comment to the + * right of the field: + * - "in", input argument, user has to provide this value, kernel doesn't modify it; + * - "out", output argument, kernel sets this field with VMA data; + * - "in/out", input and output argument; user provides initial value (used + * to specify maximum allowable buffer size), and kernel sets it to actual + * amount of data written (or zero, if there is no data). + * + * If matching VMA is found (according to criterias specified by + * query_addr/query_flags, all the out fields are filled out, and ioctl() + * returns 0. If there is no matching VMA, -ENOENT will be returned. + * In case of any other error, negative error code other than -ENOENT is + * returned. + * + * Most of the data is similar to the one returned as text in /proc//maps + * file, but procmap_query provides more querying flexibility. There are no + * consistency guarantees between subsequent ioctl() calls, but data returned + * for matched VMA is self-consistent. + */ +struct procmap_query { + /* Query struct size, for backwards/forward compatibility */ + __u64 size; + /* + * Query flags, a combination of enum procmap_query_flags values. + * Defines query filtering and behavior, see enum procmap_query_flags. + * + * Input argument, provided by user. Kernel doesn't modify it. + */ + __u64 query_flags; /* in */ + /* + * Query address. By default, VMA that covers this address will + * be looked up. PROCMAP_QUERY_* flags above modify this default + * behavior further. + * + * Input argument, provided by user. Kernel doesn't modify it. + */ + __u64 query_addr; /* in */ + /* VMA starting (inclusive) and ending (exclusive) address, if VMA is found. */ + __u64 vma_start; /* out */ + __u64 vma_end; /* out */ + /* VMA permissions flags. A combination of PROCMAP_QUERY_VMA_* flags. */ + __u64 vma_flags; /* out */ + /* VMA backing page size granularity. */ + __u32 vma_page_size; /* out */ + /* + * VMA file offset. If VMA has file backing, this specifies offset + * within the file that VMA's start address corresponds to. + * Is set to zero if VMA has no backing file. + */ + __u64 vma_offset; /* out */ + /* Backing file's inode number, or zero, if VMA has no backing file. */ + __u64 inode; /* out */ + /* Backing file's device major/minor number, or zero, if VMA has no backing file. */ + __u32 dev_major; /* out */ + __u32 dev_minor; /* out */ + /* + * If set to non-zero value, signals the request to return VMA name + * (i.e., VMA's backing file's absolute path, with " (deleted)" suffix + * appended, if file was unlinked from FS) for matched VMA. VMA name + * can also be some special name (e.g., "[heap]", "[stack]") or could + * be even user-supplied with prctl(PR_SET_VMA, PR_SET_VMA_ANON_NAME). + * + * Kernel will set this field to zero, if VMA has no associated name. + * Otherwise kernel will return actual amount of bytes filled in + * user-supplied buffer (see vma_name_addr field below), including the + * terminating zero. + * + * If VMA name is longer that user-supplied maximum buffer size, + * -E2BIG error is returned. + * + * If this field is set to non-zero value, vma_name_addr should point + * to valid user space memory buffer of at least vma_name_size bytes. + * If set to zero, vma_name_addr should be set to zero as well + */ + __u32 vma_name_size; /* in/out */ + /* + * If set to non-zero value, signals the request to extract and return + * VMA's backing file's build ID, if the backing file is an ELF file + * and it contains embedded build ID. + * + * Kernel will set this field to zero, if VMA has no backing file, + * backing file is not an ELF file, or ELF file has no build ID + * embedded. + * + * Build ID is a binary value (not a string). Kernel will set + * build_id_size field to exact number of bytes used for build ID. + * If build ID is requested and present, but needs more bytes than + * user-supplied maximum buffer size (see build_id_addr field below), + * -E2BIG error will be returned. + * + * If this field is set to non-zero value, build_id_addr should point + * to valid user space memory buffer of at least build_id_size bytes. + * 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 bytes + * for kernel to fill with matched VMA's name (see vma_name_size field + * description above for details). + * + * 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 bytes + * for kernel to fill with matched VMA's ELF build ID, if available + * (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 */ +}; + +#endif /* _UAPI_LINUX_FS_H */ From patchwork Tue Jun 18 22:45:25 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrii Nakryiko X-Patchwork-Id: 13703116 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 20205C2BA1A for ; Tue, 18 Jun 2024 22:45:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CB7BA8D006F; Tue, 18 Jun 2024 18:45:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C640B8D0066; Tue, 18 Jun 2024 18:45:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AB5488D006F; Tue, 18 Jun 2024 18:45:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 8A4928D0066 for ; Tue, 18 Jun 2024 18:45:54 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 37A52C0B87 for ; Tue, 18 Jun 2024 22:45:54 +0000 (UTC) X-FDA: 82245493428.07.2E3B56A Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf19.hostedemail.com (Postfix) with ESMTP id 8FF301A000C for ; Tue, 18 Jun 2024 22:45:52 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=USfw6ppf; spf=pass (imf19.hostedemail.com: domain of andrii@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=andrii@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=1718750745; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=YE47zTswLtVm2nHY1MKC88+b4jDA3vOIJ0oDH/6LR9U=; b=4DLq9ym8WANs9W6MLuX03O5TPNH40reqTftu7FsAGddAANROYNAd7Zn2Dyj5uhyREflal6 Xxh9lkRkDPkd4G8aDknwPLqTnVMVIgqtIKWYdeqK7PrAbgu9q745dHNnb7hZxCAmX4D0AP z5g/1I2ekMgTsJuiKIocp0ZGyYQyP8Q= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718750745; a=rsa-sha256; cv=none; b=MbGTjdXOz8zk9nEvU+kPGpDWF2wVSsvNgIh5J1bZZMuVEioz0nXjij6Eml6eZaHq/Rxlxu +wrhtYkZnhG9NgtzHPwnrwhWy5p0QABJUKm+vFfsPEt/hAjLf/BEGremcNOrwZlDn1B+GN PyPZa1la/UBJhPas2J3YvB58tziVV4s= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=USfw6ppf; spf=pass (imf19.hostedemail.com: domain of andrii@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=andrii@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id D2A1760EE1; Tue, 18 Jun 2024 22:45:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5CAA0C3277B; Tue, 18 Jun 2024 22:45:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1718750751; bh=UCwCLJEQqsSSL94rfskjH98zL7sdkNEm83V+CMuhWVw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=USfw6ppfGIjNUTiuavW9dQC8gfdnNBuEaUjuH/boEbWAouvqA3H6Wij7krpHmGNjC gFDbQ13curSzlczjnfuHUlD1TM306vNjGcxfV2V10HLNBVss6k/MCUKnjYKlmXDuON IQsQ9pFnpwA3IqgqkaSdVsY6wPQGCzB8k8qyHMXveWyJ1SwN2hDeHQUdXoGry/fvS5 lZy97mchtRRMq1GBPVdaqyzENuy98w3ghDMHpdGNI7xsLBcJ+KB8YxEfldj3osaGVe qydpeVPPVt6f+MFriHe+gnjhGGypCqe4K5KMGNLMfo5kV2Idw1eEbXm1AMNFOBhD56 VkoHkjzIyXVbg== From: Andrii Nakryiko To: linux-fsdevel@vger.kernel.org, brauner@kernel.org, viro@zeniv.linux.org.uk, akpm@linux-foundation.org Cc: 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, Andrii Nakryiko Subject: [PATCH v5 6/6] selftests/proc: add PROCMAP_QUERY ioctl tests Date: Tue, 18 Jun 2024 15:45:25 -0700 Message-ID: <20240618224527.3685213-7-andrii@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240618224527.3685213-1-andrii@kernel.org> References: <20240618224527.3685213-1-andrii@kernel.org> MIME-Version: 1.0 X-Stat-Signature: 75y6f5fdjdcz1bauskfe6ob47k76d14m X-Rspamd-Queue-Id: 8FF301A000C X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1718750752-42831 X-HE-Meta: U2FsdGVkX18tW6HqDzngYHS3ijrH5Dx927FZGIcJWC8oxyJF+P4Q/8vuYjX8KA2zq/4irYcqQbluWXHiUBiUKG+b/ecnwMyCz9xcbfT1AcEVFQsKKGm/ZxNs3WrsbCZSLLvlo2nKqc8ZdpzlhnRBae+76Q5JcYRPZdhfl+CDpQqfzcy9lC+cYO4feg19/WqKszoIs8o/E7JpCR0GUfLyjL2djlpyicFLn9X7uOCaX1sX80x6TE2QKzuu2G+NR02qwXXyOSMYU2911LPV1pTCWMAOn5QNvQAbRKwdRWoeLobVDF1a9Rk669isrKjZjqjUiaKqXgdjiUyMADJsfGCM8qXj/WLA59+ps0HsDjHFqYT2H+/VpoP4gXS/BkHDWZdm8U8fBrsUOzqgbpruPFDl0L8KlVzLA7MKgT2c1Gc+2rB64uyWdl+6981KiOq3qBu0k5zNVAiotxCN8+Qb9Bdzi25t+dVUAaOjKYsp3/z84nbmts4KP0FmVsQuE70xEsG0lbVBChxWCHEbNpeBa74ZUtVT1ok3spBTgn3M91hVchQ7BsvfVhcnhVLv0cO/8oigiaSQZh6pPWrypYdkAyp+FMfN/7DBNJdzkDOOWhCNZB7sV8OtaV+1yTy+O7+B5yXAPcQYi1FDTWT9GnYbH/aAsieqLSoBfuCmmjt4J8J4gMQuwaE0POWXBdo5SJoegwCNAuRo3gFVPJH3IFvvqazmZvE+7Yzk8LCf9VNVZtd4Fve/QEXnmiBoTAiEmMvWjHE6NKa5sATR2p6COp63OsIJfLTNHZh2oOl+Bfkt32IEz31ppGV4ESGQ0z6SGGJ8IHxdqs6OoyI0J43gWqmtdn/TKxndrymyBcawj0JlE/eH5JT7xXcqdMIXoJVPmSfN+WaGn7lrSRlzCT72xRyOno5+WdZiGiAbttPHrczXpr8v0lYQKiiu8gn6jGsA/4g3BKlhV4t/uaTZ6tDwQyNm+qR FkGdTKTt xhYQIMXaiyBwIMTFfc71bonhW8dq2CBZmdHYHHFtyf1vSHIVzAVvOO+Qz8+ib0eyPgrpSGuARewWgW03rtwSpHSSxON1DzaOOa1jN4J3l9jApdv6t/JaZc/+cCXYyIcPeibH6PtIZJbbBDYv7g1vxM09KMzXqZ6hU1ARYtwa0Z+lvv/TiMyp4XxIzuj5a4rMXNPdDVdFFGod4cydmsB86OhPPygr8lCuVq6G+//oEWENdFMr1YTn/8EpGHiQdQAN8ZHe36G8WBJ/FtCzo3S0W2MGPey0xtESIANqO 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: Extend existing proc-pid-vm.c tests with PROCMAP_QUERY ioctl() API. Test a few successful and negative cases, validating querying filtering and exact vs next VMA logic works as expected. Signed-off-by: Andrii Nakryiko --- tools/testing/selftests/proc/Makefile | 1 + tools/testing/selftests/proc/proc-pid-vm.c | 86 ++++++++++++++++++++++ 2 files changed, 87 insertions(+) diff --git a/tools/testing/selftests/proc/Makefile b/tools/testing/selftests/proc/Makefile index cd95369254c0..291e7087f1b3 100644 --- a/tools/testing/selftests/proc/Makefile +++ b/tools/testing/selftests/proc/Makefile @@ -1,6 +1,7 @@ # SPDX-License-Identifier: GPL-2.0-only CFLAGS += -Wall -O2 -Wno-unused-function CFLAGS += -D_GNU_SOURCE +CFLAGS += $(TOOLS_INCLUDES) LDFLAGS += -pthread TEST_GEN_PROGS := diff --git a/tools/testing/selftests/proc/proc-pid-vm.c b/tools/testing/selftests/proc/proc-pid-vm.c index cacbd2a4aec9..d04685771952 100644 --- a/tools/testing/selftests/proc/proc-pid-vm.c +++ b/tools/testing/selftests/proc/proc-pid-vm.c @@ -45,6 +45,7 @@ #include #include #include +#include #include "../kselftest.h" @@ -492,6 +493,91 @@ int main(void) assert(buf[13] == '\n'); } + /* Test PROCMAP_QUERY ioctl() for /proc/$PID/maps */ + { + char path_buf[256], exp_path_buf[256]; + struct procmap_query q; + int fd, err; + + snprintf(path_buf, sizeof(path_buf), "/proc/%u/maps", pid); + fd = open(path_buf, O_RDONLY); + if (fd == -1) + return 1; + + /* CASE 1: exact MATCH at VADDR */ + memset(&q, 0, sizeof(q)); + q.size = sizeof(q); + q.query_addr = VADDR; + q.query_flags = 0; + q.vma_name_addr = (__u64)(unsigned long)path_buf; + q.vma_name_size = sizeof(path_buf); + + err = ioctl(fd, PROCMAP_QUERY, &q); + assert(err == 0); + + assert(q.query_addr == VADDR); + assert(q.query_flags == 0); + + assert(q.vma_flags == (PROCMAP_QUERY_VMA_READABLE | PROCMAP_QUERY_VMA_EXECUTABLE)); + assert(q.vma_start == VADDR); + assert(q.vma_end == VADDR + PAGE_SIZE); + assert(q.vma_page_size == PAGE_SIZE); + + assert(q.vma_offset == 0); + assert(q.inode == st.st_ino); + assert(q.dev_major == MAJOR(st.st_dev)); + assert(q.dev_minor == MINOR(st.st_dev)); + + snprintf(exp_path_buf, sizeof(exp_path_buf), + "/tmp/#%llu (deleted)", (unsigned long long)st.st_ino); + assert(q.vma_name_size == strlen(exp_path_buf) + 1); + assert(strcmp(path_buf, exp_path_buf) == 0); + + /* CASE 2: NO MATCH at VADDR-1 */ + memset(&q, 0, sizeof(q)); + q.size = sizeof(q); + q.query_addr = VADDR - 1; + q.query_flags = 0; /* exact match */ + + err = ioctl(fd, PROCMAP_QUERY, &q); + err = err < 0 ? -errno : 0; + assert(err == -ENOENT); + + /* CASE 3: MATCH COVERING_OR_NEXT_VMA at VADDR - 1 */ + memset(&q, 0, sizeof(q)); + q.size = sizeof(q); + q.query_addr = VADDR - 1; + q.query_flags = PROCMAP_QUERY_COVERING_OR_NEXT_VMA; + + err = ioctl(fd, PROCMAP_QUERY, &q); + assert(err == 0); + + assert(q.query_addr == VADDR - 1); + assert(q.query_flags == PROCMAP_QUERY_COVERING_OR_NEXT_VMA); + assert(q.vma_start == VADDR); + assert(q.vma_end == VADDR + PAGE_SIZE); + + /* CASE 4: NO MATCH at VADDR + PAGE_SIZE */ + memset(&q, 0, sizeof(q)); + q.size = sizeof(q); + q.query_addr = VADDR + PAGE_SIZE; /* point right after the VMA */ + q.query_flags = PROCMAP_QUERY_COVERING_OR_NEXT_VMA; + + err = ioctl(fd, PROCMAP_QUERY, &q); + err = err < 0 ? -errno : 0; + assert(err == -ENOENT); + + /* CASE 5: NO MATCH WRITABLE at VADDR */ + memset(&q, 0, sizeof(q)); + q.size = sizeof(q); + q.query_addr = VADDR; + q.query_flags = PROCMAP_QUERY_VMA_WRITABLE; + + err = ioctl(fd, PROCMAP_QUERY, &q); + err = err < 0 ? -errno : 0; + assert(err == -ENOENT); + } + return 0; } #else