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 0BE5EC36001 for ; Wed, 19 Mar 2025 23:58:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9802A280003; Wed, 19 Mar 2025 19:58:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 92E76280002; Wed, 19 Mar 2025 19:58:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7D0E0280003; Wed, 19 Mar 2025 19:58:24 -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 5D16E280002 for ; Wed, 19 Mar 2025 19:58:24 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 9E434A9903 for ; Wed, 19 Mar 2025 23:58:24 +0000 (UTC) X-FDA: 83239967328.21.AC93187 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf04.hostedemail.com (Postfix) with ESMTP id C97AE40007 for ; Wed, 19 Mar 2025 23:58:22 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b=q+zJaD5Z; spf=pass (imf04.hostedemail.com: domain of gregkh@linuxfoundation.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org; dmarc=pass (policy=none) header.from=linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742428703; 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=8O/MMZvUQvLm75a2sTKmWstzruEZY65RpshaO5vR9kY=; b=tAYphAyaakD/K479LqZyRNClDED8eA7fuXymwg8I/czwpwkEX3fpYS6b8DTKOSpNcX8x7Y fxHnKar8PgntRFAiQnN3Uz5Pi7bO0cusCAmZy2Yv9GcRUrorHl5tZlX8iWgexjZK2F0xCt IvMVFcHLIyUunOZrWe+H9WDzqJFxMI4= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b=q+zJaD5Z; spf=pass (imf04.hostedemail.com: domain of gregkh@linuxfoundation.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org; dmarc=pass (policy=none) header.from=linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742428703; a=rsa-sha256; cv=none; b=ojqBlndlumeuhZuseO+PlYRfKqpUiZ8cPlMylzNsiIdgCnnocwS2ewZ2hn7ejvNh9eJQ/Z TkzdJ2zSygvvLl9SKU3zJCeknow4eyCgEfc84WtJCX7KJ1BNYj1blTMBren/XJO9QnrZgH dHdxpRwhUCmdFpUFVwGvYOfDNZ7gbSs= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 1498D42BAD; Wed, 19 Mar 2025 23:58:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5FDC3C4CEE4; Wed, 19 Mar 2025 23:58:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1742428701; bh=rSoECxcX9b+KRE1xg6jEVohUbJ3UCjA1B7aestxTcxw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=q+zJaD5ZkbHyP65BU62zb0Z09w1g8gdTKWaro2JmheI6rghm/wSVjxss59SjF+HkY ghX1cHNnun2clJl+F8/XZIGBHM8Shbn5pDWMl5zoX/DWIMP6mbWkDdI+KYvtYL60o5 exXZV9mru0SWOyahtPKOPl1WAimpdJ/TO0RkkxfE= Date: Wed, 19 Mar 2025 16:57:02 -0700 From: Greg Kroah-Hartman To: Lorenzo Stoakes Cc: Andrei Vagin , David Hildenbrand , 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 Subject: Re: [PATCH 1/2] fs/proc/task_mmu: add guard region bit to pagemap Message-ID: <2025031926-engraved-footer-3e9b@gregkh> References: <521d99c08b975fb06a1e7201e971cc24d68196d1.1740139449.git.lorenzo.stoakes@oracle.com> <857b2c3f-7be7-44e8-a825-82a7353665fb@redhat.com> <09d7ca19-e6cc-4aa9-8474-8975373bdebd@redhat.com> <10c3e304-1a6d-45ac-a3ad-7c0c8d00e03f@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <10c3e304-1a6d-45ac-a3ad-7c0c8d00e03f@lucifer.local> X-Rspam-User: X-Rspamd-Queue-Id: C97AE40007 X-Rspamd-Server: rspam03 X-Stat-Signature: s6skbwdtex4381sx6jtcerqy5h7w4ozh X-HE-Tag: 1742428702-557949 X-HE-Meta: U2FsdGVkX1+xsnNuq3l58YorbGEo53ElaqeNAZ7mNQ/8tIWrhBcGHCkS/aulLyHse9kEjG3aP0LAYg7zf4pyNBFBJEc/vvRALrKY3XHPpFZydZNd+ehAPc1mq4FvZ43XyUcazwzbBUomw6VuZyEG7YIiSOqvkJgC6/PuPF7gx3UgA3zXO9+24eMGjNNGpDCvh2BeoBcp4jIVKk5ighV0yAnz9D12EyXkPcz/WGvQM+lVkW2Ixz+YPF+popTGuT08CPv57PWBRDo3ucifX8M1/xmJDNB10YZM+G3wiXddrQyQwB9gxFYx/tIPnDawzXCGz0bZazqLjFnqNUQ/jS13un53P1BDo5ETMMnvGExBuowdOY5usDAY+EjiG+gNbTS0FZKZ4zAN5qv8UWi1O7WDhayxNkGSxTxMtX4liAXs0yMvL7qMM3XW7ZNIF69z07jnTtvIp0rmMNbcnMMRDv1drEs9Doyw2VTCtLbZgbqf6zZtih8NnvWYkl2AOQYaUK9kGdA1s2qM70OOF0rgS09vk3Y5+Qm++e7Qbnrn5oAawljCqyy9EMRHDS4i5aU9HGH5v8L2XveK66sVQpMJkF/tdr4q4LDlDiKzkb/s/7CF1tKcmK7etF5PCTd3XOstekOybUea30D+dtAaF7SOJGOBQlno9wOwJD+G4/EvlB4IIFiZP8YuKDD+B9B6yATxxUhpUGTDLgaCv+CdHJ5SAAWn8yc2B8WchIhArjxeKY3FrWdaL8QemNZtXWcHIfpQGUWOFxdZNRWadGiEtgcpEZfjnFLN7wx1zSKHulkw5uc8RyQ7LqLIUi42jFxH2SnFjhzc/9czQ/BcJxkAkYIwbsystpSPYSmJM2uQjsesbzDqHA2sE/KH8GUYa2wNVUOr6Bp8bg2Cs7MH+AlBiTGtRnXvliVEvb0INHV4hwfv2OS+4DcH1WvluGrXKrWHiQnl28vWGNeCuKKkUBmm5phxzjv Pvrg5Tgc Dlgxirp7wzXhXPwfHsIL69aJw9fyYGk5BsKnEBLRcrwDrDDfXoE37Z2ZsfQ9lSbt7EkwBJKKMKZymLKdHFo8VH3JJYY7ESk5PmpXWBPNlEs7ic5k6zYkhq/zm0qxC+zcKT5gaFILked38CfssCCSoqjvIAwbfbEZX4PzH7BO77+X/aj+Ys8cLJZZWS1FQZCvtmbPND3pUJkh5K49Sb3+NwBl0pf9aKUZbh5MTDHaoKu6aDfBwa9ZZYiEZSPtUV60HitpbbzJVO9IltOZU68FtHmc+dmtd/V0vVU/Trsn5aqmidMVU+znYApi9HCY+PVatrI3+2lZJW1V4hnaKANd9T7fO8Jf7qPcF4YSWbpS8JGGRTLMgcUGTFTBUIJN2yoNHAL5cs24wKem/AD/URbqvFuZZj9IaQzXZmM0RW4sCKrCcnpqNuZ8ltQcNkEbcBNcDwGiFn+r3+6EK0g+L+5WsbizBFgqC/twDdwbjCtupns+JWTzSCxMl0xLdXJXc6AVXSENipW7QmY2H5m4= 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 Wed, Mar 19, 2025 at 07:12:45PM +0000, Lorenzo Stoakes wrote: > +cc Greg for stable question > > On Wed, Mar 19, 2025 at 11:22:40AM -0700, Andrei Vagin wrote: > > On Mon, Feb 24, 2025 at 2:39 AM David Hildenbrand wrote: > > > > > > On 24.02.25 11:18, Lorenzo Stoakes wrote: > > [snip] > > > >> > > > >> 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 the > > > > tests seem to establish uffd, and the man page implies it: > > > > > > > > To start tracking the written state (flag) of a page or range of > > > > memory, the UFFD_FEATURE_WP_ASYNC must be enabled by UFFDIO_API > > > > ioctl(2) on userfaultfd and memory range must be registered with > > > > 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 excited > > > > 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/d18912fc88f3dc7bde5fdfa3575691977eb21753/criu/pagemap-cache.c#L178 > > > > Yeah we ascertained that - is on my list, LSF coming up next week means we > aren't great on timing here, but I'll prioritise this. When I'm back. > > > For CRIU, obtaining information about guard regions is critical. > > Without this functionality in the kernel, CRIU is broken. We probably should > > consider backporting these changes to the 6.13 and 6.14 stable branches. > > > > I'm not sure on precedent for backporting a feature like this - Greg? Am > happy to do it though. If it's a regression, sure, we can take it for stable. > As a stop gap we can backport the pagemap feature if Greg feels this is > appropriate? Which do the maintainers of the code feel is appropriate? I'll defer to them for making that call :) thanks, greg k-h