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 941F1C433DB for ; Sat, 6 Feb 2021 02:36:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 23D4964E46 for ; Sat, 6 Feb 2021 02:36:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 23D4964E46 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 58BF86B0005; Fri, 5 Feb 2021 21:36:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 53CCD6B006C; Fri, 5 Feb 2021 21:36:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3D2226B006E; Fri, 5 Feb 2021 21:36:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0149.hostedemail.com [216.40.44.149]) by kanga.kvack.org (Postfix) with ESMTP id 21FE46B0005 for ; Fri, 5 Feb 2021 21:36:34 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id D8C1A181AEF1D for ; Sat, 6 Feb 2021 02:36:33 +0000 (UTC) X-FDA: 77786279466.13.blow13_510c290275e9 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin13.hostedemail.com (Postfix) with ESMTP id B8AE618140B67 for ; Sat, 6 Feb 2021 02:36:33 +0000 (UTC) X-HE-Tag: blow13_510c290275e9 X-Filterd-Recvd-Size: 7228 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf27.hostedemail.com (Postfix) with ESMTP for ; Sat, 6 Feb 2021 02:36:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1612578992; 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=xVM8jheEqSMk2QyHpvwNWebjlFDs65NWkUd4v2wDYHc=; b=YRXcloxJq+dXmL/Y1HT8DPphUK4yvOBIttALdlNvgU5/c1TiD1qR8frbiAzVQqCm278eAC nRMgeOaS3xle6gv+9h4TUBUVB3nQpy1ycZU0MQZdrjAHiecpF8EUZ6CmF7RUYIAiPORktl UKhK3raBDAYWMcUxFKccMpyNE7HkzjQ= Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-439-kw2lkonRNaKNnKz2oIvH7w-1; Fri, 05 Feb 2021 21:36:30 -0500 X-MC-Unique: kw2lkonRNaKNnKz2oIvH7w-1 Received: by mail-qt1-f199.google.com with SMTP id c19so6693519qtp.2 for ; Fri, 05 Feb 2021 18:36:30 -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=xVM8jheEqSMk2QyHpvwNWebjlFDs65NWkUd4v2wDYHc=; b=iU1fx4LneTqWBzf1ooVFIAtZimyazFGH/09mb3UUZK/MJ9uCMtMjNjg5Jttu4Y3Nhi sHDWM2HoFTAZNxfbAn6G/PLlRjSDqzRpN2qnEZeU2upgqWnm0Ycr8VHY2fqBs1C2GsZH PNppxym4181LwiXvG6Q24EuaSc1DH9yR+weqU7vXSyAxcHm0h3pG82d5niyC6roZodBQ gKz3tpfogogaBkvpfaMBSEwYzQsfIWxNmJlptOmWCa2rDPRsgStLdOx1dsuv290iJjlY ISxeYUBfaLjSQRWlzVVIMweCHb6f0DgMN3KVSB0Ek7KJmdSC2A7N2dHjBzlip/ak9oTd Z12A== X-Gm-Message-State: AOAM532z8+waxewml2yhXidhM6n5ZWN8LfFYg3qrQBl0fJYd9cHQhfiE POh1Ym7yCRMDjnCxKt9amQ8PrHCwFmB1AzYr1/1XEZc996umLXPe1acmLZxBZAsLn2Jwu68pgKV 8MR2Yex7JTec= X-Received: by 2002:a0c:b49f:: with SMTP id c31mr7466425qve.35.1612578990210; Fri, 05 Feb 2021 18:36:30 -0800 (PST) X-Google-Smtp-Source: ABdhPJwoex5HpvPBM5UvEfsNE1ESwri7iRSz/V+1Pew+eLURB2aJovcfzWvRPgnMa/eebtLPb7GYuQ== X-Received: by 2002:a0c:b49f:: with SMTP id c31mr7466406qve.35.1612578989882; Fri, 05 Feb 2021 18:36:29 -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 17sm12540565qtu.23.2021.02.05.18.36.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Feb 2021 18:36:29 -0800 (PST) Date: Fri, 5 Feb 2021 21:36:27 -0500 From: Peter Xu To: Mike Kravetz Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Mike Rapoport , Jerome Glisse , "Kirill A . Shutemov" , Hugh Dickins , Axel Rasmussen , Matthew Wilcox , Andrew Morton , Andrea Arcangeli , Nadav Amit Subject: Re: [PATCH RFC 00/30] userfaultfd-wp: Support shmem and hugetlbfs Message-ID: <20210206023627.GD3195@xz-x1> References: <20210115170907.24498-1-peterx@redhat.com> <20210129224938.GC260413@xz-x1> <339d27e8-9f34-3e80-2910-46f46d58e9a6@oracle.com> MIME-Version: 1.0 In-Reply-To: <339d27e8-9f34-3e80-2910-46f46d58e9a6@oracle.com> 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 01:53:34PM -0800, Mike Kravetz wrote: > On 1/29/21 2:49 PM, Peter Xu wrote: > > On Fri, Jan 15, 2021 at 12:08:37PM -0500, Peter Xu wrote: > >> This is a RFC series to support userfaultfd upon shmem and hugetlbfs. > ... > > 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. > > My apologies for not looking at this sooner. Even now, I have only taken > a very brief look at the hugetlbfs patches. > > Coincidentally, I am working on the 'BUG' that soft dirty does not work for > hugetlbfs. As you can imagine, there is some overlap in handling of wp ptes > set for soft dirty. In addition, pmd sharing must be disabled for soft dirty > as here and in Axel's uffd minor fault code. Interesting to know that we'll reach and need something common from different directions, especially when they all mostly happen at the same time. :) Is there a real "BUG" that you mentioned? I'd be glad to read about it if there is a link or something. > > No objections to the overall approach based on my quick look. Thanks for having a look. So for hugetlb one major thing is indeed about the pmd sharing part, which seems that we've got very good consensus on. The other thing that I'd love to get some comment would be a shared topic with shmem in that: for a file-backed memory type, uffd-wp needs a consolidated way to record wr-protect information even if the pgtable entries were flushed. That comes from a fundamental difference between anonymous and file-backed memory in that anonymous pages keep all info in the pgtable entry, but file-backed memory is not, e.g., pgtable entries can be dropped at any time as long as page cache is there. I goes to look at soft-dirty then regarding this issue, and there's actually a paragraph about it: While in most cases tracking memory changes by #PF-s is more than enough there is still a scenario when we can lose soft dirty bits -- a task unmaps a previously mapped memory region and then maps a new one at exactly the same place. When unmap is called, the kernel internally clears PTE values including soft dirty bits. To notify user space application about such memory region renewal the kernel always marks new memory regions (and expanded regions) as soft dirty. I feel like it just means soft-dirty currently allows false positives: we could have set the soft dirty bit even if the page is clean. And that's what this series wanted to avoid: it used the new concept called "swap special pte" to persistent that information even for file-backed memory. That all goes for avoiding those false positives. > > I'll try to take a closer look at the areas where efforts overlap. I dumped above just to hope maybe it could help a little bit more for the reviews, but if it's not, I totally agree we can focus on the overlapped part. And, I'd be more than glad to read your work too if I can understand more on what you're working on with the hugetlb soft dirty bug, since I do feel uffd-wp is servicing similar goals just like what soft-dirty does, so we could share a lot of common knowledge there. :) Thanks again! -- Peter Xu