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=-6.1 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 E179FC433E0 for ; Sat, 6 Feb 2021 02:47:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7559B64F91 for ; Sat, 6 Feb 2021 02:47:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7559B64F91 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D36D16B0005; Fri, 5 Feb 2021 21:47:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CE6136B006C; Fri, 5 Feb 2021 21:47:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BD5B76B006E; Fri, 5 Feb 2021 21:47:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0080.hostedemail.com [216.40.44.80]) by kanga.kvack.org (Postfix) with ESMTP id A3E5F6B0005 for ; Fri, 5 Feb 2021 21:47:17 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 6E4E0180AD80F for ; Sat, 6 Feb 2021 02:47:17 +0000 (UTC) X-FDA: 77786306514.22.sign28_1d09786275e9 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin22.hostedemail.com (Postfix) with ESMTP id 4DC1018038E60 for ; Sat, 6 Feb 2021 02:47:17 +0000 (UTC) X-HE-Tag: sign28_1d09786275e9 X-Filterd-Recvd-Size: 5583 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf05.hostedemail.com (Postfix) with ESMTP for ; Sat, 6 Feb 2021 02:47:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1612579636; 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=+wyoDc8XOR2cj3A6BtGWJ+SBoGGxhF/HLXZdPPz1zrI=; b=NfkxfGo2USee1vFlwiWtx8eX6/u+Mq7m+pJowFwztAjH3uZhBs584mJbhGgAMJsNWyeIl3 zR++SutSs5Aa956RB3T1qSc9KtbnJlBF/OS3xK1bnIef2bIgdF10sQEKD7P4hlc8XKTIz5 /XL5t343v6QhJxKa4oZEd7c0pXbmmrc= 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-393-NDXigK9AODyflRdn44e7FQ-1; Fri, 05 Feb 2021 21:47:14 -0500 X-MC-Unique: NDXigK9AODyflRdn44e7FQ-1 Received: by mail-qv1-f72.google.com with SMTP id k20so6424858qvm.16 for ; Fri, 05 Feb 2021 18:47:14 -0800 (PST) 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=+wyoDc8XOR2cj3A6BtGWJ+SBoGGxhF/HLXZdPPz1zrI=; b=X6AgAPWyRz4AakmeZcd4JSK+XlNjMvJWd3PtDsqWu7Y72kkStF/9RBzPNkXr6WQZNF 34Uc/eoPwxAmxlgkq6g+qzEG+y+Ux35tFc56Y8laPiYcQfY07AM6w6ro04016AstX4al bGUrqV+l7QLvJihlyYklHy5FHi06ccGN568BhD65QR25mMIneOTCQEzBCH424/48XHHb LR+d79LsmBhz60trNqFb5bNNWN/bQZU9CxAp0xj/odqkncEjhvqlqNPcToj8OW51OZ5B /3snPkDS1fmWYZLet4GrAxSVb5aCZYF4b/GIH7rcVKmjqv4DztvUY5Hcy7TfPhOi0KcN 2lBQ== X-Gm-Message-State: AOAM531JQzdzv907MQMTh192nZRWZGsxvVUA3NPofbiZEUYknsQxqh2R 9JNR3WY3F9gUshF1ZGKm9ShaFvlB/A8TccDYLK7ZjvAC37ayoAutBe1vz5SgnjUvlgd9Zymw8S0 UVrBiBx5OucM= X-Received: by 2002:a37:9d53:: with SMTP id g80mr7350174qke.307.1612579634199; Fri, 05 Feb 2021 18:47:14 -0800 (PST) X-Google-Smtp-Source: ABdhPJzeKIuLtR8y4v8gCIkyTs9rsJZfFFo+tzRDqiO6R5CA7Iai/cKcEqVyrzhf/2UEe5+FVdUrcw== X-Received: by 2002:a37:9d53:: with SMTP id g80mr7350163qke.307.1612579633991; Fri, 05 Feb 2021 18:47:13 -0800 (PST) Received: from xz-x1 (bras-vprn-toroon474qw-lp130-20-174-93-89-182.dsl.bell.ca. [174.93.89.182]) by smtp.gmail.com with ESMTPSA id 22sm11848068qke.123.2021.02.05.18.47.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Feb 2021 18:47:13 -0800 (PST) Date: Fri, 5 Feb 2021 21:47:11 -0500 From: Peter Xu To: Hugh Dickins Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Mike Rapoport , Mike Kravetz , Jerome Glisse , "Kirill A . Shutemov" , Axel Rasmussen , Matthew Wilcox , Andrew Morton , Andrea Arcangeli , Nadav Amit Subject: Re: [PATCH RFC 00/30] userfaultfd-wp: Support shmem and hugetlbfs Message-ID: <20210206024711.GE3195@xz-x1> References: <20210115170907.24498-1-peterx@redhat.com> <20210129224938.GC260413@xz-x1> MIME-Version: 1.0 In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=peterx@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline 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 Fri, Feb 05, 2021 at 02:21:47PM -0800, Hugh Dickins wrote: > On Fri, 29 Jan 2021, Peter Xu wrote: > > > > Huge & Mike, > > > > Would any of you have comment/concerns on the high-level design of this series? > > > > It would be great to know it, especially major objection, before move on to an > > non-rfc version. > > Seeing Mike's update prompts me to speak up: I have been looking, and > will continue to look through it - will report when done; but find I've > been making very little forward progress from one day to the next. > > It is very confusing, inevitably; but you have done an *outstanding* > job on acknowledging the confusion, and commenting it in great detail. I'm honored to receive such an evaluation, thanks Hugh! As a quick summary - what I did in this series is mostly what you've suggested on using swp_type==1 && swp_offset=0 as a special pte, so the swap code can trap it. The only difference is that "swp_type==1 && swp_offset=0" still uses valid swp_entry address space, so I introduced the "swap special pte" idea hoping to make it clearer, which is also based on Andrea's suggestion. I hope I didn't make it even worse. :) It's just that I don't want to make this idea that "only works for uffd-wp". What I'm thinking is whether we can provide such a common way to keep some records in pgtable entries that point to file-backed memory. Say, currently for a file-backed memory we can only have either a valid pte (either RO or RW) or a none pte. So maybe we could provide a way to start using the rest pte address space that we haven't yet used. Please take your time on reviewing the series. Any of your future comment would be greatly welcomed. Thanks, -- Peter Xu