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.5 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 CC6A5C433B4 for ; Fri, 14 May 2021 12:31:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5CDA0613D6 for ; Fri, 14 May 2021 12:31:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5CDA0613D6 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 CBD156B0036; Fri, 14 May 2021 08:31:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C6CD86B006E; Fri, 14 May 2021 08:31:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ABF536B0070; Fri, 14 May 2021 08:31:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 769866B0036 for ; Fri, 14 May 2021 08:31:14 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 10890BF19 for ; Fri, 14 May 2021 12:31:14 +0000 (UTC) X-FDA: 78139771668.14.128A57C Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf25.hostedemail.com (Postfix) with ESMTP id D947C60006F4 for ; Fri, 14 May 2021 12:31:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1620995473; 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=0wcDpE/Q+m1DFHQZr7axynmSMqacQ9s1VDrFV+vCPSw=; b=jIznZmZ3EOlhmOrWjLQzDMRfhw6NlAqwAhoxyVUqgN0nk+BQfIC1gDSjdXW+ACg6EddNaM fYkpY4KtNVQFDzQDeSVF+BBk8wlM5thbGBT5t7AyNq1ssN7H+ljIKPxICm9VByKbN/Aoin vXOhvQMtPSut/6mPidrrkjcERZk//wI= Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-594-4-e6gWyWM32ncZ_x4hAsLQ-1; Fri, 14 May 2021 08:31:11 -0400 X-MC-Unique: 4-e6gWyWM32ncZ_x4hAsLQ-1 Received: by mail-qk1-f197.google.com with SMTP id s68-20020a372c470000b0290305f75a7cecso6985413qkh.8 for ; Fri, 14 May 2021 05:31:11 -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=0wcDpE/Q+m1DFHQZr7axynmSMqacQ9s1VDrFV+vCPSw=; b=aAzt5lWiDN4BWNt3tQT/KFZubE49Mi+6PlOXB2SyocRYsxfF3ArP4fTYCXXJeWDcCr Ne/VfLrKG2C0+QsQ1IlerK/a4EP7akRDnj4+ZIVzrYCMr7T7PkS77XIf2AQVJnzwQCmI 6HTf1Tm+02z+NnTZ3ZW13CsMZIqZ1zhWefYi7hKJG9q00bU0EkAw9MAhPEcyG3rXmP05 brup+2XfBbfr1ZJUhYMrkL4AFQ8NBT2qXKqHWy4sGQprxcV14rVhwvHCgI+essz9wnn0 BFdPMJl88zAR11yuJDUbD+3QhUWqNGAg5l60h/nRpk1WocUhHTUno9WESpFgWdjME237 COTg== X-Gm-Message-State: AOAM530qP0yUyIf3X0sulAX8p2yn/Q9CoGaJIF+w6Lvsuweqcyawgcnk I2VlNXo5Zi6qA1tdNAZH9iBTC5Eb0sK0nsG6zYlkrOAz/f4wdrhRaAtNSaXnCsphBtXmP9ExgiN XzzvS6tKlz/Y= X-Received: by 2002:a37:f512:: with SMTP id l18mr42878518qkk.89.1620995470944; Fri, 14 May 2021 05:31:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyUc7ycbD+8M+157LnMfInY8crn9Z3vRgQFv1/EnGb3Xrs/M5OLOrdoQdqzSDyHPZxJim98iQ== X-Received: by 2002:a37:f512:: with SMTP id l18mr42878477qkk.89.1620995470612; Fri, 14 May 2021 05:31:10 -0700 (PDT) Received: from t490s (bras-base-toroon474qw-grc-72-184-145-4-219.dsl.bell.ca. [184.145.4.219]) by smtp.gmail.com with ESMTPSA id n15sm4462637qti.51.2021.05.14.05.31.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 May 2021 05:31:10 -0700 (PDT) Date: Fri, 14 May 2021 08:31:09 -0400 From: Peter Xu To: Mike Kravetz Cc: Mina Almasry , Axel Rasmussen , Linux-MM , Andrew Morton , open list Subject: Re: [PATCH] mm, hugetlb: fix resv_huge_pages underflow on UFFDIO_COPY Message-ID: References: <20210513234309.366727-1-almasrymina@google.com> <09dc0712-48e8-8ba2-f170-4c2febcfff83@oracle.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Queue-Id: D947C60006F4 Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=jIznZmZ3; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf25.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=peterx@redhat.com X-Rspamd-Server: rspam03 X-Stat-Signature: txqi67cpixsf194bcs3pqbp5dpxfzz9e X-HE-Tag: 1620995471-93743 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: Hi, Mike, On Thu, May 13, 2021 at 09:02:15PM -0700, Mike Kravetz wrote: [...] > I am also concerned with the semantics of this approach and what happens > when a fault races with the userfaultfd copy. Previously I asked Peter > if we could/should use a page found in the cache for the copy. His > answer was as follows: > > AFAICT that's the expected behavior, and it need to be like that so as to avoid > silent data corruption (if the page cache existed, it means the page is not > "missing" at all, then it does not suite for a UFFDIO_COPY as it's only used > for uffd page missing case). I didn't follow the rest discussion in depth yet... but just to mention that the above answer was for the question whether we can "update the page in the page cache", rather than "use a page found in the page cache". I think reuse the page should be fine, however it'll definitely break existing user interface (as it'll expect -EEXIST for now - we have kselftest covers that), meanwhile I don't see why the -EEXIST bothers a lot: it still tells the user that this page was filled in already. Normally it was filled in by another UFFDIO_COPY (as we could have multiple uffd service threads) along with a valid pte, then this userspace thread can simply skip this message as it means the event has been handled by some other servicing thread. (This also reminded me that there won't be a chance of UFFDIO_COPY race on page no page fault at least, since no page fault will always go into the uffd missing handling rather than filling in the page cache for a VM_UFFD_MISSING vma; while mmap read lock should guarantee VM_UFFD_MISSING be persistent) Thanks, -- Peter Xu