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 A078CC433ED for ; Wed, 12 May 2021 02:35:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 047B7616E8 for ; Wed, 12 May 2021 02:35:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 047B7616E8 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 454D46B0036; Tue, 11 May 2021 22:35:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 404756B006E; Tue, 11 May 2021 22:35:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 256E76B0070; Tue, 11 May 2021 22:35:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0159.hostedemail.com [216.40.44.159]) by kanga.kvack.org (Postfix) with ESMTP id 0A0C96B0036 for ; Tue, 11 May 2021 22:35:15 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id BACA7181AF5D0 for ; Wed, 12 May 2021 02:35:14 +0000 (UTC) X-FDA: 78131012148.07.F5ECFEA Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf14.hostedemail.com (Postfix) with ESMTP id A48C0C0007CD for ; Wed, 12 May 2021 02:34:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1620786913; 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=G4lfT9fW4g3rEz0SGgc+Nositq7mKE+i7OSsXREwu/Q=; b=AYbjwpv+DBKYZ2wd6CvOi1iqNbM2+3rCOxMxUnORIhB3Gzp7K829F90PlFvjRglS2pweFa e8WdxzQLgUUjfzEdspjl5bNPjwrkFrdarHZVvT2AnPD73JwV758ai4pE3oj1XLTUa3kvRU 4u50vrkhwvR38eR/uh6mRIap0kL+3tI= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-244-JIdekV1DNQ-1YXh_Gy1QCQ-1; Tue, 11 May 2021 22:35:12 -0400 X-MC-Unique: JIdekV1DNQ-1YXh_Gy1QCQ-1 Received: by mail-qv1-f71.google.com with SMTP id d21-20020a0caa150000b02901e2ed83f922so9884778qvb.4 for ; Tue, 11 May 2021 19:35:12 -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=G4lfT9fW4g3rEz0SGgc+Nositq7mKE+i7OSsXREwu/Q=; b=kS5Sh6U4NizleUd1tWNjhXyVk1ZAaBfA+K6HFcgfkEWB0jA0v12xfuKxJvFzFKXPdo ji0gHNj1fUk6JWusvdCt1WOtv1frFq35qZOFljf2uMOkYnz1+Xct4f9KNNR3WCvFcKzp zpu1U1W6qUPY2rR8ngNyKmhsA2lrRzM0ch78jWRq0c7DWX31e5LAes7LCQrU44iQwAwK oAC45mHk7T1BuDiuhPudU7gHm1ONzrQqfALN3ZvYgg0YFVm6a/s0Bdu8jl0ydrJYPPk3 +BJ/rOna9R8PGT1pZiMy3bNccPcRK07GFmpkLThEfHNx924VQz3vszJLq1tpZbplr9Ny 4e5w== X-Gm-Message-State: AOAM530HvHyf54bGbs4KgljOFY7RAxoUEf/MH2NdMCGewHbo/9CxNqpY amYUK3Nxr5JmE4Jw6XbU6xkQngiDRxpLEN7sQd7U6Ob+CB/xMNak3FUqr5qZA3DUxanFM3RFISV HQJ34PXw/f4s= X-Received: by 2002:a37:f91a:: with SMTP id l26mr31228436qkj.55.1620786911635; Tue, 11 May 2021 19:35:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyhngtzV6X9De+KIUj6Ljs06qPE9maym6BeWLEbmwChXbHqQe4Z2Qs/vAOONtN3bMwOsp/ycQ== X-Received: by 2002:a37:f91a:: with SMTP id l26mr31228418qkj.55.1620786911350; Tue, 11 May 2021 19:35:11 -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 r8sm14864241qtc.24.2021.05.11.19.35.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 May 2021 19:35:10 -0700 (PDT) Date: Tue, 11 May 2021 22:35:10 -0400 From: Peter Xu To: Mike Kravetz Cc: Mina Almasry , Linux-MM , Axel Rasmussen , aarcange@redhat.com Subject: Re: resv_huge_page underflow with userfaultfd test Message-ID: References: <096e28e2-5937-beb2-57f7-d112f9b54d97@oracle.com> MIME-Version: 1.0 In-Reply-To: <096e28e2-5937-beb2-57f7-d112f9b54d97@oracle.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=AYbjwpv+; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf14.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: rspam05 X-Rspamd-Queue-Id: A48C0C0007CD X-Stat-Signature: bjtbpnt14t7ik9rhmr8wmx6udid5oe7t Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf14; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=170.10.133.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1620786889-292438 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: Mike, On Tue, May 11, 2021 at 07:25:39PM -0700, Mike Kravetz wrote: > I looked at this a bit more today and am not exactly sure of the > expected behavior. The situation is: > - UFFDIO_COPY is called for hugetlb mapping > - the dest address is in a shared mapping > - there is a page in the cache associated with the address in the > shared mapping > > Currently, the code will fail when trying to update the page cache as > the entry already exists. The shm code appears to do the same. > > Quick question. Is this the expected behavior? Or, would you expect > the UFFDIO_COPY to update the page in the page cache, and then resolve > the fault/update the pte? 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). Thanks, -- Peter Xu