From patchwork Tue Jun 11 11:00:53 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrii Nakryiko X-Patchwork-Id: 13693432 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 E7548C25B76 for ; Tue, 11 Jun 2024 11:01:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D1A206B00B3; Tue, 11 Jun 2024 07:01:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C9EA16B00B4; Tue, 11 Jun 2024 07:01:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AA73A6B00B5; Tue, 11 Jun 2024 07:01:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 7B9FC6B00B3 for ; Tue, 11 Jun 2024 07:01:20 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 317ADC1489 for ; Tue, 11 Jun 2024 11:01:20 +0000 (UTC) X-FDA: 82218316320.04.2246A67 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf15.hostedemail.com (Postfix) with ESMTP id 80736A002A for ; Tue, 11 Jun 2024 11:01:18 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="tP81B/tI"; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf15.hostedemail.com: domain of andrii@kernel.org designates 139.178.84.217 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=1718103678; 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=OkCHTAsFlJWRbK0KwrLwuOSgEGBAJd1XNMflclCcVvc=; b=TOyPLR8KRbMY7YGlObU17j/km2NB9DlpPGNBqbDXWAeTKD+d9hjM2pRB1gaE8XOFCZlu1k r+h0tJmiF8NbWGoISpdLLQCsDighS/x/UeaPW8n9yMCtdbSC2I8DgCR8N5OyqSIvFXBSvx ot6bzt80evriqNs6ZSDR3vhV4OeOe/4= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="tP81B/tI"; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf15.hostedemail.com: domain of andrii@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=andrii@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718103678; a=rsa-sha256; cv=none; b=sjxurHX2IDgpUzjFowy8qudKrV1l0RYzygdMOWT7fXK6JlGmhG+z0Geb/i1XYaUuQv6w9C bSLtdd7Z38uUwSEuNqoDxqztO0PXgf/x6D9y8uetaKG5ypz1evdeUomQFqHXOwb7iWRkzp cXUoN2nQ2gWvkbmOEPvLZADtvS0+2TI= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 7F2F860DD3; Tue, 11 Jun 2024 11:01:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 14522C32789; Tue, 11 Jun 2024 11:01:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1718103677; bh=XhT7MyIpfN/Vsi8sYrA9Vx1PIwjnTH2I6tc+o8hojXY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tP81B/tIMOmXFuFB/8IHeIDqgEW9Euh+r5om1kwPttzwAcAJeEeS69AwTNxTF9Swf /HWLcv5OA4tBUIXlpoo05hABs+eg8SkHY/TT8rjnD88P7nSYmcxLbAtpbbJ7UWM1F0 m4boTr6jMa3O7gQ75Qf+CQW3xL2kHF8H4ceuHWUOTxfYtM47Tq8FOl9KHfvEc7C8VJ y4o4eJD23DNIWi9BKc6fegdXH32dGJVZPSJzaR8OdP+O2wOfB1bi/cN1ocf4Qo8TYY 2EQtXLXo9tTSE0IBdU9Hr4tFOEhljOUt7QMmmf9IH1wh8/ZR14eeG+FyzKz3t36RnZ bfWF6sj2hoVMw== 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, Andrii Nakryiko Subject: [PATCH v4 5/7] tools: sync uapi/linux/fs.h header into tools subdir Date: Tue, 11 Jun 2024 04:00:53 -0700 Message-ID: <20240611110058.3444968-6-andrii@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240611110058.3444968-1-andrii@kernel.org> References: <20240611110058.3444968-1-andrii@kernel.org> MIME-Version: 1.0 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 80736A002A X-Stat-Signature: i5c9a79jd5tr1ua6qzpuopzjff4k7xam X-Rspam-User: X-HE-Tag: 1718103678-979195 X-HE-Meta: U2FsdGVkX1/KmPBT+k11sxbWOPi54FNIwbVorY+MIiytRFIK+32wHjLGFWLzPyDf1y6Gn4pZIGovDUQAfXoRTmm/iZiK4U1lvwBr/8yrIwTF493pWjv+CTP1At+BCXqc+D2GNXXcWpjlxmveuYU9/1hUtHkHNtAUUNSnkqZFXkzM2i3xN+P4Nm9VM+VCYCiyB6iIi+TzeRvK0T3fly15dP1WWslvVfZ2i9LIyIKkx7eP/oJXA/6EpwJv+Cwu/4k+bKibpeQxURdHxibzpe0nJPA8gaH2tagFIAY3/pCW5Lf09jYLCK00swAdvy54hWkPFK7vWHzL8E+oUroSIjPt4UrT0ImrpjiCfzUqiQj/u/g7ON6PHHD2D75fy2bFbmUTawjic0/oUOd2wcVkEPVO8J40SgMN8roQ5ObDcF0I9eXEjtAykUn8IanVjVYF2qMwSz8QghRyIiy4K3wmJ7NFOUyNNXTaNqsQaDoUayd8ysYCrNKNaLRc7UWblkWBC2WL6bnHGX45qZhdYWa6HWGTV+3ltXMj7DLbN5Y7xMXFRSHvLbct91BF5jg82EHVPe92NUG9cG5moep2TmGZwkGiPfPn3v9Pj2/ZNvVjkktheriZ9LeTLRrcqNtm5fqomk5aHL+7cN3Wvye73F0CgntloSDzdI7zsDANtaoA2t3vsX6uB/3NVDE3AEZfngWSRoncZGOW1YqOrfxUqyCL7JAX5eJOOLgJozUFO/84e+ZyrWDZql3mtiI7t4LbG/aQtNJ5axGQLHVDrqXS6/18E0BT3CrN5y6aBSpCH02n/3juLVy2CIGqUzMPeCMoZLpbX9rDF8wqpoaAdaJ0cQ/wX1MAqSr1pPMZ6fKH88xA/5fToK2rWI/+YJNZrzKrM/qeEDNLOtHiL1R7hCV4ml/+5CFMpwKS/H1h5pR/eWVlgweW1xdQA6ZbrsAqNHr1ZVAxh8y1az3/pWGA5KTTn0kFMte 63RHPjKC HFimiqjPp443fTfYQjsFp4YqEsBenTysG2cxbJG5Ta4QQKb5ogviUJbjrF6fmefM3ul+9leZp5EhckA71icxXD0yfRmWJ/8pBgdLMWICo3p2VTUDgj/eU2/chdMYG+aBatipzOLRz9xGcx5N3w5lxikOhYIqGEsauA1visLDFnHaievMOA4uY+JcGQFjl2pxfldLLmWYRo7qN8DrSd/AY2zOwNWEPZN7BuHDE4v9ILtAa7rX7+D64u+D7yQ== 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 | 550 ++++++++++++++++++++++++++++++++++ 1 file changed, 550 insertions(+) create mode 100644 tools/include/uapi/linux/fs.h diff --git a/tools/include/uapi/linux/fs.h b/tools/include/uapi/linux/fs.h new file mode 100644 index 000000000000..7306022780d3 --- /dev/null +++ b/tools/include/uapi/linux/fs.h @@ -0,0 +1,550 @@ +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ +#ifndef _UAPI_LINUX_FS_H +#define _UAPI_LINUX_FS_H + +/* + * This file has definitions for some important file table structures + * and constants and structures used by various generic file system + * ioctl's. Please do not make any changes in this file before + * sending patches for review to linux-fsdevel@vger.kernel.org and + * linux-api@vger.kernel.org. + */ + +#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 + * the file limit at runtime and only root can increase the per-process + * 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.. + */ + +/* Fixed constants first: */ +#undef NR_OPEN +#define INR_OPEN_CUR 1024 /* Initial setting for nfile rlimits */ +#define INR_OPEN_MAX 4096 /* Hard limit for nfile rlimits */ + +#define BLOCK_SIZE_BITS 10 +#define BLOCK_SIZE (1</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 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 */