From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7C98DC3064D for ; Wed, 26 Jun 2024 16:38:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EE5626B008A; Wed, 26 Jun 2024 12:38:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E94336B0093; Wed, 26 Jun 2024 12:38:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D0DFC6B009A; Wed, 26 Jun 2024 12:38:07 -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 AD6376B008A for ; Wed, 26 Jun 2024 12:38:07 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 5A5421C30C8 for ; Wed, 26 Jun 2024 16:38:07 +0000 (UTC) X-FDA: 82273597014.06.64F25CA Received: from mail-oo1-f43.google.com (mail-oo1-f43.google.com [209.85.161.43]) by imf22.hostedemail.com (Postfix) with ESMTP id 9C37BC0013 for ; Wed, 26 Jun 2024 16:38:05 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=X+cZxkGG; spf=pass (imf22.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.161.43 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719419869; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=2cVIcPPhEBUXqRMcxG1yeOT4hiCfThHRsp+pkbaR8/k=; b=l2o6LCZaBmVCkj9tuJ6tgFHnGJslbevmAbAE9S5N4VJlmKBFQQi6PwtyI6+PzxKOUzM5i6 z61Jo7Ct+dzogNZpvVuAK6A8SmGzB+ra+Q+/zXHiAcGsK2SH78OFS73xJfxmp50c9L1RQF iz8md5XM11sV4FbgADQ1GoJAc1zDSxQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719419869; a=rsa-sha256; cv=none; b=aIYqpjiSx2Xv7q0tLdlfxI+X6/c9VMfuT6Bqy31pCxcsk3fPYrwDlho6TG7Zrgy5++W/fx gbI+hz6Fu74W2qukNqjic66G+zFjtKsv5NUZH7DxtdydmHvASQ4iYuqL+2ACc5fzPiSct5 yG/D8yh3+0RpzDb96n+ewiP/4YZP7Ss= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=X+cZxkGG; spf=pass (imf22.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.161.43 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-oo1-f43.google.com with SMTP id 006d021491bc7-5c21ef72be3so684852eaf.2 for ; Wed, 26 Jun 2024 09:38:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719419884; x=1720024684; darn=kvack.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=2cVIcPPhEBUXqRMcxG1yeOT4hiCfThHRsp+pkbaR8/k=; b=X+cZxkGGocQIO0DZzEfa2LdJ/LwN97uzBQFBgjoJivmntgph9u+R8mrTTEqu5laBaW 6k9QM0/LReBJQtXi+qgEscn8P4wJ0x2H8lQUxE4nPUmU0iigX0zOgEq0gAm1p8deHJVL JxRnUwUt0LgYUQUauHvVSX9dQHII/HSZCIg6d6x4EpZtQBI4INR1R71mmK+eRuAOJr7m gCg2oo9QHJf0Y078bpk5n6o1lfllcwJNCaLAM/p+tVceeVX2i2esfeuswTbSGQzos6bI Gnv386OHOiE/hqvGH4wOWItJ36LFdm9y+JUnvrExW6NnGT7qWy5yNrMskQrj7AbBiPFM DaXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719419884; x=1720024684; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=2cVIcPPhEBUXqRMcxG1yeOT4hiCfThHRsp+pkbaR8/k=; b=ZZwiUjakD5p7piJK+8ZfITPrh0in6h1q5uIkYNPVECbL3cRlxwo8tl7TtbG9Ymp+zi mdnoP9j/TE7vdV02YtNZOqZ3B3cH3q3NfiyzsrsLBS1WmtpcgS1/KKhrKSzZqQnzQh3i V7AEpCZaD1R0z59zDMfalPizDJ3PBLBlWo9FbuBB0msvAzxmq2dUZ0sN8u6nqMfSi/me wvxluHd8bSEdTylQckZqcXcRx/ojSnElwOCg/IKpxcfUC2bTm5ygZSNTBXK2G6DkAI2m IKcUsbtYL+vg/9JO42iVDkKFFN6pQxaeqDQInVSn4S/p6pJDL7xGfkPVhCr4VxG+4+pX AcqQ== X-Forwarded-Encrypted: i=1; AJvYcCVL7hCpGSIYasffoHHIHc46iWQH780jxQqiLT4js/JpfTEKNNYEWGW7UcgaXKwQuAaiszepGGTz9xu9QbMHCXmnvDw= X-Gm-Message-State: AOJu0Ywnsgxh9amrOMdmrmqhk0twe/arFoO9nmBm94RfbCdkq1B7qdWe J3RMvKlcxWiN/M2O+Dwxn08AifcVzPXcyu2SG4VsVjA5ZomJ5AaGeiyUVF2dNKntWbs0Pfqy/mr AMQiQvg6Ty65f7dY8IiBeHkWittY= X-Google-Smtp-Source: AGHT+IHuBq5hOd4/sH4F3EqjcgWE0azLRGW9R1NFwiXC36XTHUOyVWiNVokhWGI3FOhlNhfWMoV0QGG2Ek9o51kOgRM= X-Received: by 2002:a05:6358:885:b0:1a2:11a9:cba with SMTP id e5c5f4694b2df-1a23fb90e10mr1357551355d.12.1719419884411; Wed, 26 Jun 2024 09:38:04 -0700 (PDT) MIME-Version: 1.0 References: <20240618224527.3685213-1-andrii@kernel.org> <20240618224527.3685213-3-andrii@kernel.org> In-Reply-To: From: Andrii Nakryiko Date: Wed, 26 Jun 2024 09:37:52 -0700 Message-ID: Subject: Re: [PATCH v5 2/6] fs/procfs: implement efficient VMA querying API for /proc//maps To: "Liam R. Howlett" , Andrii Nakryiko , linux-fsdevel@vger.kernel.org, brauner@kernel.org, viro@zeniv.linux.org.uk, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, bpf@vger.kernel.org, gregkh@linuxfoundation.org, linux-mm@kvack.org, surenb@google.com, rppt@kernel.org, adobriyan@gmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 9C37BC0013 X-Stat-Signature: 97m9rpextjubmqu7emskp8iw58tny7nm X-HE-Tag: 1719419885-621567 X-HE-Meta: U2FsdGVkX1+hk6uMFIF3B/QoTu/Oo09fmGRezeGb6CJJzXmLv/kUVSbd+ZaH1MTJQ0naVGg7MXVnHQnJxwvhOpmoQrtddYgLj1Q39cChHzv+D82EbDR2PTgP//+KX6O1XzeV+P20Cb5WLNzeDSs9W35sMIHAtNKsD6Y1rI50Kltg6WsAVpBw6Hge1ESJNmJ9TJ4hHV4VE6Bl3gByunBc1ud5bG5NkGBQZa4fkF4R6rlod8d3N21n85qjtmUzkq9qdUALbOLXMTU0IoQ0gYK7b6IJZaYW1p6e9YU0Kee6afmxBgQMkJIPNFzRNRXDtmhEABGWPQF78vcAxYVwcZOUOI5rlVRZq/LmXS6n1qT7zJd8ay0ADqDOy4v2UmojPgiNJUCBJpeXQWioPjALN5i8y46ZjOuJh5KY3Cyj7Xd5F5nvLkbOEuPeUMCBAESNZ4h8VAL6r5TEopPUrSIFh9HmhjQZ2qhuCbtz7GRTkcTpdoDmj31Pjx3BYKk8XKkL657NFkJFooudsflwGFgbDBT8RKlqoiNjN1Cev2dbBeOW5Jj5qX7JcTyZHQmcN78Zp5WBNTl5eyy37b1l4fTVRArD6TR478pyw9IBqihYIqXdiX5HV6nyT/2fJuauGU3BLLk0/TklKqfE3V6V8CBOLvktsjCWkQ+4kG1bPUT5rxD3OtxT3dPi/8wQfhDELWUw6dntYKLC5jaSX3Nodtw8jZL6gJKR34iCclG7wLXAebjSyxZkErL0PgbZc9mWvAyje4XFDdpmi+6GId1MmQaZTc0hDsbBcE7sa5QNvW+46sDJQMvoZrC6huz6isqS/jZL0wublsRDBZFHCSBFS+8S/Tj+vZEMc3Eq+O6SvqqTW1eN6WGNdFKZlioAJX+5f/952XqAIsuJTm92PUssMzKXZrBYnet7zDRdvCxM8YrzVhVZkvVIj5BZxjP+44c9B9rkeZdu9BM7jxgYHkxgkT79ztg oHwIeVwb Dpfv1gXuc6i335GrD+YxtIAupwqpkllrIguihUxwUq7+DkeDPOmISQ30TsVqAxM3htfu1J+BXRwCSb9UTfpexI4SlNpwD+Ks7ktUVgmCCfRbgWFMTHQn4WQJ5GtiHzUqTAitSo8glMe3xWAB3JNqPlE760dQaJfPbq2RIFTsqc59RXtu+ZR2YCmHwSwyEQoECzaq9w3KHcIrkgV9JGCengCXMSXmXGz/jnKmSPIaaLX+4WJVV90jl3OwN/A8Vs3CDgiM9mi/dMfdoNSXLSZm++2oVAWcza0+DadX8fesn9VRhT3fNo9W9rUOUyEkOYuZxBnDnQ5SseXCsV6wG2YQGB1ENtN1VDKq24JVE+9VDeAQ7n64fmVZrNDkN3bascMjKpVwDdFi1tu4OP+RHYhknqXwWhK+r6v111wIM X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Jun 25, 2024 at 7:42=E2=80=AFPM Liam R. Howlett wrote: > > * Andrii Nakryiko [240618 18:45]: > ... > > > + > > +static int do_procmap_query(struct proc_maps_private *priv, void __use= r *uarg) > > +{ > > + struct procmap_query karg; > > + struct vm_area_struct *vma; > > + struct mm_struct *mm; > > + const char *name =3D NULL; > > + char *name_buf =3D 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_add= r fields */ > > + if (usize < offsetofend(struct procmap_query, query_addr)) > > + return -EINVAL; > > + err =3D 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 !=3D !!karg.vma_name_addr) > > + return -EINVAL; > > + > > + mm =3D priv->mm; > > + if (!mm || !mmget_not_zero(mm)) > > + return -ESRCH; > > + > > + err =3D query_vma_setup(mm); > > + if (err) { > > + mmput(mm); > > + return err; > > + } > > + > > + vma =3D query_matching_vma(mm, karg.query_addr, karg.query_flags)= ; > > + if (IS_ERR(vma)) { > > + err =3D PTR_ERR(vma); > > + vma =3D NULL; > > + goto out; > > + } > > + > > + karg.vma_start =3D vma->vm_start; > > + karg.vma_end =3D vma->vm_end; > > + > > + karg.vma_flags =3D 0; > > + if (vma->vm_flags & VM_READ) > > + karg.vma_flags |=3D PROCMAP_QUERY_VMA_READABLE; > > + if (vma->vm_flags & VM_WRITE) > > + karg.vma_flags |=3D PROCMAP_QUERY_VMA_WRITABLE; > > + if (vma->vm_flags & VM_EXEC) > > + karg.vma_flags |=3D PROCMAP_QUERY_VMA_EXECUTABLE; > > + if (vma->vm_flags & VM_MAYSHARE) > > + karg.vma_flags |=3D PROCMAP_QUERY_VMA_SHARED; > > + > > + karg.vma_page_size =3D vma_kernel_pagesize(vma); > > + > ... > > > +/* > > + * Input/output argument structured passed into ioctl() call. It can b= e 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 do= esn't modify it; > > + * - "out", output argument, kernel sets this field with VMA data; > > + * - "in/out", input and output argument; user provides initial valu= e (used > > + * to specify maximum allowable buffer size), and kernel sets it t= o 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 ioct= l() > > + * 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 a= re no > > + * consistency guarantees between subsequent ioctl() calls, but data r= eturned > > + * 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_f= lags. > > + * > > + * 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 VM= A is found. */ > > + __u64 vma_start; /* out */ > > + __u64 vma_end; /* out */ > > + /* VMA permissions flags. A combination of PROCMAP_QUERY_VMA_* fl= ags. */ > > + __u64 vma_flags; /* out */ > > + /* VMA backing page size granularity. */ > > + __u32 vma_page_size; /* out */ > > The vma_kernel_pagesize() returns an unsigned long. We could > potentially be truncating the returned value (although probably not > today?). This is from the vm_operations_struct pagesize, which also > returns an unsigned long. Could we switch this to __u64? > Yep, fair point. It seemed excessive to use u64, but I guess nothing prevents us (in the future) from having humongous pages with >4GB sizes. I'll update to __u64. I'll wait for a few more hours just in case I get some other feedback, and will rebase and post a new revision later today, thanks. > ... > > Thanks, > Liam