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 X-Spam-Level: X-Spam-Status: No, score=-7.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F2E3AC63798 for ; Thu, 22 Jul 2021 18:30:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 91B0460E73 for ; Thu, 22 Jul 2021 18:30:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 91B0460E73 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id A489A6B005D; Thu, 22 Jul 2021 14:30:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9F8FF6B0071; Thu, 22 Jul 2021 14:30:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8C1186B0072; Thu, 22 Jul 2021 14:30:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0104.hostedemail.com [216.40.44.104]) by kanga.kvack.org (Postfix) with ESMTP id 736606B005D for ; Thu, 22 Jul 2021 14:30:45 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 198CF180AD81F for ; Thu, 22 Jul 2021 18:30:45 +0000 (UTC) X-FDA: 78391064850.14.71ECD38 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 719D1801B0EF for ; Thu, 22 Jul 2021 18:30:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1626978643; 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: in-reply-to:in-reply-to:references:references; bh=GJnRg6RexQrbbpxlDEJWagNuxouahMFP2JB9+XDpj+8=; b=GavrnMJ2Y16vGJWRVeqFJ1XyvALJuch6J5oqcScc/4JcSdMBY5QpmpMoILZ2IGCsjUdpo9 jfAOX54n652RNwKPM3Wi4OdlkQgIk0MWUZZXybCx4iBk+sx7Vk1c19ujj+/07FO23YuKYt xomplV2sws7KNdnwmXdo903YX2Vq0tM= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-438-vOB6dav6MaKC_0JvYGDlYw-1; Thu, 22 Jul 2021 14:30:42 -0400 X-MC-Unique: vOB6dav6MaKC_0JvYGDlYw-1 Received: by mail-qv1-f72.google.com with SMTP id 10-20020a0562140d0ab02902ea7953f97fso72977qvh.22 for ; Thu, 22 Jul 2021 11:30:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=GJnRg6RexQrbbpxlDEJWagNuxouahMFP2JB9+XDpj+8=; b=Pt3sxeopjrefcFG9wOGu1zCozaVFo3TVbuUyXgD70YECAunEuG9Gf4eFpQTRKXykb6 uwA7c61/hoRX05U/TaPaMCm7VlQOpAB8v3CPPEwpAmeWUXkPye1clcBk0TjAvYgOtk7L JAbDSvOq/O+5a+U7+UYUDQrDGN8aOqVCUmMNNWnl7f4ddwtCp0Y4gDp5lwoR74W2EL0h lcL1PxOC7i04T58TLERDXxHTUj6WFkMiiEu/ED547pDuECNrRuWNZRoXnuf12XWM8GUY D1D5yxgP7GHKxlURowCD3Bw9+L6giOf6tGXH4AOh9EH6PE2DWrnFLeTDA4U5S24uL+3V rs+w== X-Gm-Message-State: AOAM533cZmm7gKLFBzrpWxOTKN61YnQEwlhPeIWcWLby3UeFYRHnXoyS f3mdFZ0F2Lig/eSNkFX28RIT54nLEEoPwZFH4f3Xqc6dv12OAdsFioOdseec39lXNnfeIT1FiAq SB5cstxDZ8rqg42r3XeEjzJTL4K9SDAhKcqV/u9eTs6QZsoR+eHWjxsQ2hS3H X-Received: by 2002:a05:6214:3004:: with SMTP id ke4mr1294290qvb.52.1626978641849; Thu, 22 Jul 2021 11:30:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxygV8ytkh+nSrGukKh74fabSktHwOrX1sxkgxPIt6G6Cegb9r0OTiPFxzZ37aDJM1h9qY0kQ== X-Received: by 2002:a05:6214:3004:: with SMTP id ke4mr1294251qvb.52.1626978641483; Thu, 22 Jul 2021 11:30:41 -0700 (PDT) Received: from t490s (bras-base-toroon474qw-grc-65-184-144-111-238.dsl.bell.ca. [184.144.111.238]) by smtp.gmail.com with ESMTPSA id u3sm10808922qtg.16.2021.07.22.11.30.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jul 2021 11:30:40 -0700 (PDT) Date: Thu, 22 Jul 2021 14:30:39 -0400 From: Peter Xu To: linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Jason Gunthorpe , Mike Kravetz , David Hildenbrand , Alistair Popple , Matthew Wilcox , "Kirill A . Shutemov" , Hugh Dickins , Tiberiu Georgescu , Andrea Arcangeli , Axel Rasmussen , Nadav Amit , Mike Rapoport , Jerome Glisse , Andrew Morton , Miaohe Lin Subject: Re: [PATCH v5 00/26] userfaultfd-wp: Support shmem and hugetlbfs Message-ID: References: <20210715201422.211004-1-peterx@redhat.com> MIME-Version: 1.0 In-Reply-To: <20210715201422.211004-1-peterx@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 719D1801B0EF X-Stat-Signature: 4qwub5xb719mfxc6qhphqicwymidashb Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=GavrnMJ2; spf=none (imf06.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-HE-Tag: 1626978644-341932 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: On Thu, Jul 15, 2021 at 04:13:56PM -0400, Peter Xu wrote: > About Swap Special PTE > ====================== I've got some more feedback regarding this series, either within review comment or from other threads. Hugh shared his concern on using such type of pte level operation could make things even worse: https://lore.kernel.org/linux-mm/796cbb7-5a1c-1ba0-dde5-479aba8224f2@google.com/ Since most context is irrelevant, only quotting the p.s. section: p.s. Peter, unrelated to this particular bug, and should not divert from fixing it: but looking again at those swap encodings, and particularly the soft_dirty manipulations: they look very fragile. I think uffd_wp was wrong to follow that bad example, and your upcoming new encoding (that I have previously called elegant) takes it a worse step further. Alistair shared his preference on keep using swp_entry to store these extra information: https://lore.kernel.org/linux-mm/5071185.SEdLSG93TQ@nvdebian/ So I'm trying to do some self introspection to see maybe I was just too bold to try introducing that pte idea, either I'm not the "suitable one" to introduce it as it's indeed challenging, or maybe it's as simple as we don't really need to worry using up swap address space yet, at least for now (currently worst case MAX_SWAPFILES=32-4-2-1=25). I don't yet have plan to think about Hugh's idea on further dropping the usage of per-arch bits in swap ptes, e.g. _PAGE_SWP_SOFT_DIRTY or _PAGE_SWP_UFFD_WP. I need more thoughts there. But what I can still do is think about whether we can still go back to swap entry ptes for this series. Originally I was afraid of wasting a whole type of swp entry just for one single pte, so we came up with the idea (thanks again for Andrea and Hugh on proposing and discussions around it!). But did we just worry too much on that while it comes from nothing? So as time passes, there're indeed some more similar requirements coming that has issues that look like what uffd-wp file-backed wanted to solve on pagemap, they're: - PM_SWAP info missing when shmem page swapped out - PM_SOFT_DIRTY lost when shmem page swapped out The 1st issue might be solved by other way and there're still discussed here: https://lore.kernel.org/linux-mm/YPmX7ZyDFRCuLXrh@t490s/ I don't see a good way to solve the 2nd issue (if we would like to solve it first, though; I don't know whether that's intended to not be fixed for some reason), if without similar solution like what we will like to apply to maintain the uffd-wp bit, because they're all potentially issues around persisting pte information for file-backed memories. These requirements at least show that even if we introduce a new swp type (maybe let's just call it SWP_PTE_MARKER) then uffd-wp won't be the only user, so there're already potential users of more bit out of the entry. In summary, I'm considering whether I should switch the special swap pte idea back to the swp entry idea (safer, according to Hugh, also arch-independent, according to Alistair). Before working on that, any early comment would be greatly welcomed. Thanks. -- Peter Xu