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 A3C80C35FFA for ; Wed, 19 Mar 2025 18:22:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CCC12280002; Wed, 19 Mar 2025 14:22:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C549A280001; Wed, 19 Mar 2025 14:22:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ACE9D280002; Wed, 19 Mar 2025 14:22:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 8C013280001 for ; Wed, 19 Mar 2025 14:22:55 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 8A023140483 for ; Wed, 19 Mar 2025 18:22:56 +0000 (UTC) X-FDA: 83239121952.30.6819ED5 Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) by imf30.hostedemail.com (Postfix) with ESMTP id 8727480003 for ; Wed, 19 Mar 2025 18:22:54 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ZD93iOOt; spf=pass (imf30.hostedemail.com: domain of avagin@gmail.com designates 209.85.208.177 as permitted sender) smtp.mailfrom=avagin@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=1742408574; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=VLkLWvkDX5FuoXTeYmRt1KErPEmtJ52plY5zQ5AVuCU=; b=T7XNqdOOX75/E4JwQjyt4C/dhymaquNifSSpWjek9yQuTicbc7jpt6/qy7bXvQ5TS2JT2J AytEdOY+6+KER6OVv74Jf0e7MWRy0pL7fI7vxmQIrNeh43L/Nu+vFEkribf7tvIc6hD70c SCJI/ssAPEgoB9k8hsc96GmlhCkCx2o= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742408574; a=rsa-sha256; cv=none; b=QKIKbtaSThk0VUG2rEe84ekFifgcLKbR7mtpCj9EulWBgwbTLsRG3VbY2bv4o7h3/fIbeT DOGHIMmfP2tW7rWG+pjKxchly6DNNREktQfBGWeEC+M7oklHRtSbSu0hoYp9vWHCqG8285 9EFWNV9RpBB2HybTuK9XHP1d4ixXdpM= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ZD93iOOt; spf=pass (imf30.hostedemail.com: domain of avagin@gmail.com designates 209.85.208.177 as permitted sender) smtp.mailfrom=avagin@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-lj1-f177.google.com with SMTP id 38308e7fff4ca-30c416cdcc0so72088261fa.2 for ; Wed, 19 Mar 2025 11:22:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742408573; x=1743013373; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=VLkLWvkDX5FuoXTeYmRt1KErPEmtJ52plY5zQ5AVuCU=; b=ZD93iOOtjcrzhfyPZn+b3QJDB2OYThwZMPA4ODpQatpE3n1K7/6SUsmePdQZf1iLY0 YrmASvbSc2NbYO4EwL9NyKsbBjATZ+0WwXZQxCv+LeyhaWDa6wv95+tGqfLFzBpVnI+e SusDWR3ksEXFEensdnze2tnE+RCC2mE0EHfVTO5LO7zNh1AgX3XiwMeXVlrhLDXdw3g8 h7uYe+DEKuW+Uy/99n9yX9KGy77jc9FzWaoHy833wkhDRwjJnAEyANwWx27EpI1eccqC DQ81MffTJUjjVIEiRQW91FblgJw/Mu5gMj0hMaevV7f32L6zaCCO/Rq6Bxtyzs/9mOXl hkZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742408573; x=1743013373; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=VLkLWvkDX5FuoXTeYmRt1KErPEmtJ52plY5zQ5AVuCU=; b=XqjCWZrfuaCgQSQ9ADAmQhDKt5/CTtJI/JPr9W8ixQNY30eDbOvrFYlIbAWlQGCwrn SWiJwdrTjtitXMpL+4ADXoiKwi0zJQ60dlXH/G+miraPDSRAo2IzcE/YQGlZbZ/tHkWR Mm/uRcRGO2HUHflo4MPvIfqZcue99h7MNrkOoJKhFjcWlcUY3FenvpUFql4aTMf/9UKa TxA3uoyAZFarzGtqMTpctli3083FB/aKMGADPC9RzTnepSRx6ZYGLF672GhEOp7QN7ps OdddgXkXRGsGhnSmHOktsav534cDKbbDkEnChdQA0bjoPgLkdG3Ol7MfJkRea7zZ213S a9YA== X-Forwarded-Encrypted: i=1; AJvYcCUWxSj0qgE3EI7hyZvljLdZwRu4E/M91xuab2/U9aJibiURhLR9OhZILO52GSQlj7BzjcI9fKdnDQ==@kvack.org X-Gm-Message-State: AOJu0YzLjzPIqyiyr6fRN9ODvi2ftM1XbJR0z2UjMKHDOAomU4t5Tctw j0A/Ue0MJkRHci67wEV+5LESpm/HLVYR8Wjdvofpk5/fASmuuhOHFcEZzZzawMydoZWKCXvTJxR ENEGmk2DerPpwT9vPtGLtkt9k9eg= X-Gm-Gg: ASbGncu5aiG1WSdDMJWc7rOYJq8MnR4MHbMCz9aQYAfLr3cfyRj9mhdKuJpOb4zB+Io IY4oRvx0qB7adfHYgOuemNJTagzhVPWUce/0enJbtEM/70Jv3us2oURbr91E3DiR6mG2Mch2k/1 h8EUNXGQp6th5vi1pUCJb0jykvCFU= X-Google-Smtp-Source: AGHT+IHrb+0+RW//aqL4hayGxKMukUv5CQcq0S1hKrCwbb+4QWIXnDL8Nl4vyyrv12iknXkUgnUUPfeHuJytfA0aC3k= X-Received: by 2002:a2e:8e86:0:b0:30b:f924:3554 with SMTP id 38308e7fff4ca-30d6a40df68mr11816251fa.21.1742408572336; Wed, 19 Mar 2025 11:22:52 -0700 (PDT) MIME-Version: 1.0 References: <521d99c08b975fb06a1e7201e971cc24d68196d1.1740139449.git.lorenzo.stoakes@oracle.com> <857b2c3f-7be7-44e8-a825-82a7353665fb@redhat.com> <09d7ca19-e6cc-4aa9-8474-8975373bdebd@redhat.com> In-Reply-To: <09d7ca19-e6cc-4aa9-8474-8975373bdebd@redhat.com> From: Andrei Vagin Date: Wed, 19 Mar 2025 11:22:40 -0700 X-Gm-Features: AQ5f1JruWAyKDTdp0dEzeU8snZGpGJb9hqdzmlckS-ryauSv8oXkKubpwnOYi4E Message-ID: Subject: Re: [PATCH 1/2] fs/proc/task_mmu: add guard region bit to pagemap To: David Hildenbrand Cc: Lorenzo Stoakes , Andrew Morton , Jonathan Corbet , Shuah Khan , Suren Baghdasaryan , Kalesh Singh , "Liam R . Howlett" , Matthew Wilcox , Vlastimil Babka , "Paul E . McKenney" , Jann Horn , Juan Yescas , linux-mm@kvack.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-api@vger.kernel.org, criu@lists.linux.dev, Alexander Mikhalitsyn , Pavel Tikhomirov , Mike Rapoport Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 8727480003 X-Stat-Signature: 1hrbyqrfxqanrggehka7q8ew76knrso6 X-HE-Tag: 1742408574-547641 X-HE-Meta: U2FsdGVkX19BJ60iTrH0Er644+dUzcEORBaDUTjMndK+gaeP0DnUvGo/s/wStqc2WFr3vZgsi/mq+IJ5/jzTtJ33kZsOtO9NP1OAHDSGs7brML3GdtWzGdGfv9/3pxMT+WnD/fBRwifU7DUpTzNCGDBgbYay1HL0Q3MkO9isfFvX9jqXPODOEaK/IjXBViHUkGrN++4/6M0YgSHWNDEicXKDSDKCWrUGk7xVxlSlVw7nuL6G4o15nURPNYtEDU5F+K0Vum7bHPLclR4/Q1wH1zbNT270dq/XJ9z1xBy4Gkf4IUtXqLd+7c/evY4RDlMHhZ0pc/DX+3K6JJnz1sHdI/hO94XO76bGa/sFpfIz3x5wZSg5gYQgq6oPWFCbrp38VPNzF0PjSBqjHYrAe4Wby/LJ62nPI7NSnJ8B2bDdEsT/tvlPLyOZMfoWXeiUH98CQC7XzRYiiZ0MtwKB8RV6/KqFBgxwEBAP02AhFSyT+iJe6pUe9SPBFegiCiO6ZBOfnNONKTJ9lSvevlwgmpxVZN61w7GbCpmVwmjOPg+aJ2IpxSZd6z1zC2JLsmCZwIYb/c8ynqL5giapAgkTOyzQkEKZmjBYtuLOfgMZDfy9w6gjnEoS3MLGC3wEldcp96ZF5PJ308QLVqPSHFbb5/P4voI9VaAYc0cQDh1s2NUDljw/rOmBP/IhRZPCMOoknlqXgXq8KEckwm6QMMNykf4lPVRwcQbaN7OzvWiVE9cB5h70Mfyt53Ni1m+KsYbVipXk8oeAb8Y57iv87YzWG44joQohNfzGu8vwyjRQ8Hq7Lp6eNFKMs919SHyjo9qCnCmEjqxxC08178l0TcrxaqjdQsKtFLRB9g4ekvPN+5nG2eF2MSUXloKps1Z1lt+xkGNEU1hDtaoXgADc8PvP0najPoE6Nnfc2Yipchd52lTzj/WYSDGUxZ6L7B5jQpb83ctnvgB/zWTeHDo+Uue2jhP TMOlabJ7 xa7SjF2jfxiXmpSUNzf97tqJTj2zXIOxCGO3v1gUT4tcs0vT/zMC3VdmNgUlulw1qAmlmyFy0C5yyM+z9vvrH9JYybdsSx32BZQuwlKmboZk+bc1ECoBjlrJPAbfSQyCdjmwNF0buJGm9zHF8KYyYp2oZi+i1GtpuzIV4WmD+tqKSQ8imQyxJM7MXTnva49g3JyC6DvDyaffiaSBjizEmdLFUrqqdTnhtDrK2nCUzBezqrxXUrfouGw3NdR7VoCv8TruuMrPBSzn23eueESkUSTTETtR/bwuwoxb26GKzNmkRWNFnnRSFMg4DeoYvTfaccevLn7PDyO9o/1jvc+Uk7jSli05vBN6HTCe+jdvzTESLzDH5y1RQT8DD5eMqDSA0WD9rAbe3S1MApR+e0u7XDmUqs1DTyTSivYEagNPCcUqp6/EfSE75gr+o/Wr+94uYlo4XjGc+IjhOxadnYZyu1DCIk3hjrvHLBgtu07EVLfbS8pcqU9pq/q1YpoIrmH9MLCT5 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, Feb 24, 2025 at 2:39=E2=80=AFAM David Hildenbrand wrote: > > On 24.02.25 11:18, Lorenzo Stoakes wrote: > > On Mon, Feb 24, 2025 at 10:27:28AM +0100, David Hildenbrand wrote: > >> On 21.02.25 13:05, Lorenzo Stoakes wrote: > >>> Currently there is no means by which users can determine whether a gi= ven > >>> page in memory is in fact a guard region, that is having had the > >>> MADV_GUARD_INSTALL madvise() flag applied to it. > >>> > >>> This is intentional, as to provide this information in VMA metadata w= ould > >>> contradict the intent of the feature (providing a means to change fau= lt > >>> behaviour at a page table level rather than a VMA level), and would r= equire > >>> VMA metadata operations to scan page tables, which is unacceptable. > >>> > >>> In many cases, users have no need to reflect and determine what regio= ns > >>> have been designated guard regions, as it is the user who has establi= shed > >>> them in the first place. > >>> > >>> But in some instances, such as monitoring software, or software that = relies > >>> upon being able to ascertain the nature of mappings within a remote p= rocess > >>> for instance, it becomes useful to be able to determine which pages h= ave > >>> the guard region marker applied. > >>> > >>> This patch makes use of an unused pagemap bit (58) to provide this > >>> information. > >>> > >>> This patch updates the documentation at the same time as making the c= hange > >>> such that the implementation of the feature and the documentation of = it are > >>> tied together. > >>> > >>> Signed-off-by: Lorenzo Stoakes > >>> --- > >> > >> > >> Acked-by: David Hildenbrand > > > > Thanks! :) > >> > >> Something that might be interesting is also extending the PAGEMAP_SCAN > >> ioctl. > > > > Yeah, funny you should mention that, I did see that, but on reading the= man > > page it struck me that it requires the region to be uffd afaict? All th= e > > tests seem to establish uffd, and the man page implies it: > > > > To start tracking the written state (flag) of a page or range o= f > > memory, the UFFD_FEATURE_WP_ASYNC must be enabled by UFFDIO_API > > ioctl(2) on userfaultfd and memory range must be registered wit= h > > UFFDIO_REGISTER ioctl(2) in UFFDIO_REGISTER_MODE_WP mode. > > > > It would be a bit of a weird edge case to add support there. I was exci= ted > > when I first saw this ioctl, then disappointed afterwards... but maybe = I > > got it wrong? > > > > I never managed to review that fully, but I thing that > UFFD_FEATURE_WP_ASYNC thingy is only required for PM_SCAN_CHECK_WPASYNC > and PM_SCAN_WP_MATCHING. > > See pagemap_scan_test_walk(). > > I do recall that it works on any VMA. > > Ah yes, tools/testing/selftests/mm/vm_util.c ends up using it for > pagemap_is_swapped() and friends via page_entry_is() to sanity check > that what pagemap gives us is consistent with what pagemap_scan gives us. > > So it should work independent of the uffd magic. > I might be wrong, though ... PAGEMAP_SCAN can work without the UFFD magic. CRIU utilizes PAGEMAP_SCAN as a more efficient alternative to /proc/pid/pagemap: https://github.com/checkpoint-restore/criu/blob/d18912fc88f3dc7bde5fdfa3575= 691977eb21753/criu/pagemap-cache.c#L178 For CRIU, obtaining information about guard regions is critical. Without this functionality in the kernel, CRIU is broken. We probably shoul= d consider backporting these changes to the 6.13 and 6.14 stable branches. > > >> > >> > >> See do_pagemap_scan(). > >> > >> The benefit here might be that one could effectively search/filter for= guard > >> regions without copying 64bit per base-page to user space. > >> > >> But the idea would be to indicate something like PAGE_IS_GUARD_REGION = as a > >> category when we hit a guard region entry in pagemap_page_category(). > >> > >> (the code is a bit complicated, and I am not sure why we indicate > >> PAGE_IS_SWAPPED for non-swap entries, likely wrong ...) > > > > Yeah, I could go on here about how much I hate how uffd does a 'paralle= l > > implementation' of a ton of stuff and then chucks in if (uffd) { go do > > something weird + wonderful } but I'll resist the urge :P :)) > > > > Do you think, if it were uffd-specific, this would be useful? > > If it really is completely uffd-specific for now, I agree that we should > rather leave it alone. > > > > > At any rate, I'm not sure it's _hugely_ beneficial in this form as page= map > > is binary in any case so you're not having to deal with overhead of par= sing > > a text file at least! > > My thinking was, that if you have a large VMA, with ordinary pagemap you > have to copy 8byte per entry (and have room for that somewhere in user > space). In theory, with the scanning feature, you can leave that ... > scanning to the kernel and don't have to do any copying/allocate space > for it in user space etc. PAGEMAP_SCAN doesn't have this issue and it was one of the reasons to implement it. Thanks, Andrei