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 1D875C678D4 for ; Thu, 2 Mar 2023 14:13:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5A0476B0071; Thu, 2 Mar 2023 09:13:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 550DB6B0073; Thu, 2 Mar 2023 09:13:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3F1556B0074; Thu, 2 Mar 2023 09:13:05 -0500 (EST) 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 2E69A6B0071 for ; Thu, 2 Mar 2023 09:13:05 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id E949F140F79 for ; Thu, 2 Mar 2023 14:13:04 +0000 (UTC) X-FDA: 80524149888.21.2FDA452 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf06.hostedemail.com (Postfix) with ESMTP id CE7EE180005 for ; Thu, 2 Mar 2023 14:13:00 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=JAiVSIi1; spf=pass (imf06.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677766381; a=rsa-sha256; cv=none; b=vrkpKDfTvjyAFf+KO05210jH41a3IeS+o8wVsqdNiRRdj1K0+w7/gA5yv107C9XsiMK+2u pBhM8CQgeIO1iGcQITSUpbRkhy2I5ySV7cg9WMieOwBsV+TiIp1fZJ0ycQtbGZIHxZ6W+d ydjPrBhu7Nl/Roda2xIWidsZBGkhf60= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=JAiVSIi1; spf=pass (imf06.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677766381; 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=bKd8rPEmV4UERQunTxXjSiSz/2xedTBRivrunoUSBW0=; b=kj3c6xFesMKETR9oKY/SmOlEpAZfUC/TXLOlPLMlqyHAqy4OsE3oej1anN1y/PwnTjdRzQ b105dKKYmsVzZUUER3BF8vmjefcM3aV7P3DxWsiT/VpbTQiGXz/7OySM8MftSThBGsssug uruc3dcGrlgFWRQwMaDjhg31Q5HfpWk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677766380; h=from:from: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; bh=bKd8rPEmV4UERQunTxXjSiSz/2xedTBRivrunoUSBW0=; b=JAiVSIi179iE7Jk+oZR+H3dr+HkFXiGAQnrR+ZuoabS6ORPAaX6i1IcjQChSjd4pBCzksq GhbgtV/Bab0X0Mq5FMxY6b9tC5p18hu6gtOoCeDUCWxfccAt+gWjduockfSlMLZ6ejZNKJ +ec2O3GDCYsyFflkpv0X5xzgPeOXPeo= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-202-CjWL7-BZOuyFjLwOqIA2vg-1; Thu, 02 Mar 2023 09:12:58 -0500 X-MC-Unique: CjWL7-BZOuyFjLwOqIA2vg-1 Received: by mail-wm1-f70.google.com with SMTP id e17-20020a05600c219100b003e21fa60ec1so1143608wme.2 for ; Thu, 02 Mar 2023 06:12:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:organization:from :references:cc:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=bKd8rPEmV4UERQunTxXjSiSz/2xedTBRivrunoUSBW0=; b=BIOE0C6aJHc4h1dQHnKDTNo6IdUwqpchJUCx7tVSoeZVVJxWk5GpJfvsmsIu3xx5n+ RtKNXrUePGi5MYmjOJIN2oiXvXPLUlW4DidmWG0iLZ/U6F8iaEv25h3EC43BS7jtYyLS Tbb4NZrg+7IHmKcytb2LX1Se6Fh6+kv8nY45694TaEF2LWgFzlQ+LvtdzAYyFAXLcLF/ jf+zI7QAP6fJUC27UTiHCcs0nPKbOvx8TgMr8V54lHEwZFbqkrC0SEeGigvc7NixcrIH d1GYCDGhqf0L3vemZPEIRNProc3UkcuyelL13H9oR5nsDgBSH4f66F4y+1KyTLZPItkg h6aw== X-Gm-Message-State: AO0yUKXqYIaBHYBWf9mq2CZutRoVsc8PW5Vsz8mJX+IBeXHmm4TBCzCZ oK/+AuVVzH1Iw0qEJeRuTdy893mBBYZ9ktsGSxjIL5cxc55J0uWKm/U9pR8OAQONocnUc8wn82F tItF8Z/b95z4= X-Received: by 2002:a5d:60d2:0:b0:2c5:587e:75ba with SMTP id x18-20020a5d60d2000000b002c5587e75bamr6955161wrt.55.1677766377582; Thu, 02 Mar 2023 06:12:57 -0800 (PST) X-Google-Smtp-Source: AK7set8PgLYMjCA04jBmWxGzPzlNFoZHR6pbQHNtfTO8hgS3jeCv/FIwB37mxpdQjZikJ1B3/gR81Q== X-Received: by 2002:a5d:60d2:0:b0:2c5:587e:75ba with SMTP id x18-20020a5d60d2000000b002c5587e75bamr6955144wrt.55.1677766377231; Thu, 02 Mar 2023 06:12:57 -0800 (PST) Received: from ?IPV6:2003:cb:c70e:4f00:87ba:e9e9:3821:677b? (p200300cbc70e4f0087bae9e93821677b.dip0.t-ipconnect.de. [2003:cb:c70e:4f00:87ba:e9e9:3821:677b]) by smtp.gmail.com with ESMTPSA id h8-20020adff188000000b002c54241b4fesm15245527wro.80.2023.03.02.06.12.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Mar 2023 06:12:56 -0800 (PST) Message-ID: Date: Thu, 2 Mar 2023 15:12:55 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 To: Peter Xu Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Axel Rasmussen , Mike Rapoport , Andrew Morton , Andrea Arcangeli , Nadav Amit , Muhammad Usama Anjum References: <456f8e2e-9554-73a3-4fdb-be21f9cc54b6@redhat.com> <4dbc9913-3483-d22d-bbd2-e4f510fff56d@redhat.com> <91d7c512-ee57-7d71-34b7-90e45f5c109b@redhat.com> <4b3c2f37-3b84-3147-7513-4293e5408fdd@redhat.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH] mm/uffd: UFFD_FEATURE_WP_ZEROPAGE In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Queue-Id: CE7EE180005 X-Rspamd-Server: rspam01 X-Stat-Signature: 4mshatxa6fsm9wptd5d8d3jt67w7eguw X-HE-Tag: 1677766380-539700 X-HE-Meta: U2FsdGVkX19PhuDWHIwbzdx2KP7VSDjTERZYPsTedJL9oAroo1SQ80T4OfecQYb7KNh4c1rmvavETfv4TbeX69PeNai2kvjZu7r44mKkvT48yNn7m++YbqwOwKqpvoRGV22EUsdJqSfkVUaR0/7Z8nlK/xJb5pnjU/WXcpJuGQ70jmRTanHMGeeM2cXbtznrFXGycJj4RetQ7BgtvQCI+p/gSeozkQzoeJaAAoZo5Urev9v+6Uhd3iktNenvgWLAbEitmBXV8fC2L+eWUG+EG2PKhOXVATz4YCC0q5G5uxJkQCz0/pViN+1dKlRfupmK5wc58SU1qvAUipJAqdebJmFIuiNjE2568jPcoqg1ZxBwnypiWtox78forjx+XUS93RhS/AqHFMkk9nB6f0LoFppfIUII1zjrKUS//Dz6dMXxBtTZOAHGPZXrbBzb5W2+VVrLrMc3Flm5PH4Rb2wcLu4avn5alsl7F2GquYI8IRAv7CWHwVXbj+3BNa0AnsKLvsgOHrXpWHk6IGvujal33Y8LwcoRk/12jC49lRwNbQKGA4lujjkDc1neWKk3iEpHJS27sXo/ypNKxXlUP+4XW+fFa6Q6letFx3iZ3wxSy2t83RL5/JwxdQryVNWLdoizRjShq22P+7ibJ8EahcROIlUNYCyB6565ybyouylKSGCTApvLKwmxZe5QDvYWzXRzsJLUDGkWxpjb11zLFcngK3BG5uMob1+e71WIaOXYDCfL9gIGAA8c+dX/5vS40nrHf5Z3ASp6MD7eVJbKcx8vvkyTehr4P8dOyyLz+qgd8ZCYa7+XtnKPoLD81baHXtoc30YxzvddP3fIlla6f72LcwChQRIkIQvWpIUIv+D9oTCZgZhxMxhxMRqJPrpdhcVWEL026WJ/npXP1iSHHQckOv/YXWJ7VVmSSeAX5kzx6F1g6zDKgo3QIVXV7nqJYjahTFsUmh3P7zIOnd0XX8H ZKwlf0tR T/iiS5kJmsWcn/zLoZbEKz+VWQkbe0eJleKXFsxl6M2SnwMlrGGOYB2o4okV702pl3C5k10RHMGdqagTWTyR4fK3YUJugHmwUyGAecQd/9bSKl3jCNCR6+y8OM7zfANTZKFfvTmUfm8zzQqP4dlV+zvyogXz3u9XNcXITa/6WErQXw5PUudTvFChLg+C4+6h0tt/ong+bhv0frLR+o3lD/+/lUNKCc+NidvmlurVbsusB1NOTd4gL4LC7nYp1yBT62HQ3tSBNQXQTy6ApMMngvEFzhFQBrUWcRQ9xFs9BKO3IoHNKUOdJdGzD1pcllHZfJGJw4bOI1E7dxdIcQp65kXpYauqr7L2HgfziBSI9i4iywX+k1JinCGpX6D+5jrRmMobWOyT4ID7haDeus29eLSETLe4IUsVLV3crXQUD2J9w0qs= 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: >> >> uffd-wp protecting a range: >> * !pte_none() -> set uffd-wp bit and wrprotect >> * pte_none() -> nothing to do >> * PTE_UFFD_WP -> nothing to do >> * PTE_UFFD_NO_WP -> set PTE_UFFD_WP >> >> unmapping a page (old way: !pte_none() -> pte_none()): >> * uffd-wp bit set: set PTE_UFFD_WP >> * uffd-wp bit not set: set PTE_UFFD_NO_WP >> >> (re)mapping a page (old: pte_none() -> !pte_none()): >> * PTE_UFFD_WP -> set pte bit for new PTE >> * PTE_UFFD_NO_WP -> don't set pte bit for new PTE >> * pte_none() -> set pte bit for new PTE >> >> Zapping an anon page using MADV_DONTNEED is a bit confusing. It's actually >> similar to a memory write (-> write zeroes), but we don't notify uffd-wp for >> that (I think that's something you comment on below). Theoretically, we'd >> want to set PTE_UFFD_NO_WP ("dirty") in the async mode. But that might need >> more thought of what the expected semantics actually are. >> >> When we walk over the page tables we would get the following information >> after protecting the range: >> >> * PTE_UFFD_WP -> clean, not modified since last protection round >> * PTE_UFFD_NO_WP -> dirty, modified since last protection round >> * pte_none() -> not mapped and therefore not modified since beginning of >> protection. >> * !pte_none() -> uffd-wp bit decides > > I can't say I thought a lot but I feel like it may work. I'd probably avoid > calling it PTE_UFFD_NO_WP or it'll be confusing.. maybe WP_WRITTEN or > WP_RESOLVED instead. I haven't thought about this further, but I maybe we might be able to just use a single PTE marker , because pte_none() would translate to PTE_UFFD_WP in such VMAs. So we could make the meaning of the PTE_UFFD_WP marker simply depend on the type of VMA. If I am not wrong, we could stop setting PTE_UFFD_WP completely then, for any memory type (shmem/anon/hugetlb). > > But that interface looks weird in that the protection happens right after > VM_UFFD_WP applied to VMA and that keeps true until unregister. One needs > to reprotect using ioctl(UFFDIO_WRITEPROTECT) OTOH after the 1st round of > tracking. It just looks a little bit over-complicated, not to mention we > will need two markers only for userfault-wp. I had a feeling this > complexity can cause us some trouble elsewhere. When to apply this logic is indeed the interesting part. Doing it right from the beginning when the feature is enabled sounds like the simplest approach to me. For background snapshots and dirty tracking that might just be good enough. > > IIUC this can be something done on top even if it'll work (I think the I think the API would have to change eventually, to enable it via a new feature ("unpopulated implies uffd-wp is active"). > userspace API doesn't need to change at all), so I'd suggest giving it some > more thoughts and we start with simple and working. Yes. -- Thanks, David / dhildenb