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=-5.9 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 C22F8C48BE5 for ; Thu, 17 Jun 2021 15:10:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 32122613AA for ; Thu, 17 Jun 2021 15:10:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 32122613AA 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 88A916B0072; Thu, 17 Jun 2021 11:10:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 861B26B0073; Thu, 17 Jun 2021 11:10:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 703766B0074; Thu, 17 Jun 2021 11:10:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0125.hostedemail.com [216.40.44.125]) by kanga.kvack.org (Postfix) with ESMTP id 3E10A6B0072 for ; Thu, 17 Jun 2021 11:10:50 -0400 (EDT) Received: from smtpin32.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id D340AE081 for ; Thu, 17 Jun 2021 15:10:49 +0000 (UTC) X-FDA: 78263553018.32.8C0D7CB Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf22.hostedemail.com (Postfix) with ESMTP id 976B7C00F787 for ; Thu, 17 Jun 2021 15:10:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1623942648; 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=60V2U3Y8XQYar/tao4RcgAgdvbeJ83af09NY8ZeK7JI=; b=Z72VJIypfvGUVXU6zShX1NmzF52jwyplvRlQuf54tf+yKYcrlmQ980qygWBamqB5dDUwU2 0zFswpVKf2IkcFy//mjsKbAuxFkSoBbOTuds/1oCtqOxaSMPVgtd1zQFJvS3UzMDs6Dpv2 MvhIqWbTDm/I1medMZqtEk/AIr3itYk= Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-219-jMGv1asFMW-Ypam36JUQng-1; Thu, 17 Jun 2021 11:10:45 -0400 X-MC-Unique: jMGv1asFMW-Ypam36JUQng-1 Received: by mail-qv1-f70.google.com with SMTP id p5-20020a0ccb850000b029025849db65e9so2459714qvk.23 for ; Thu, 17 Jun 2021 08:10:45 -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=60V2U3Y8XQYar/tao4RcgAgdvbeJ83af09NY8ZeK7JI=; b=Fd4irZrdlyMUqGM9fJJ3vR7giR9rgEu3xnJaE9dizsUeBQUY1DKGvKEcy236cSD0QC S3PLZ+T4I2DpxU9tpyzq0q0E4hwCNW+AvfeDV2I88HVPV6qVLzvRWbkwVxll9NSfv0mI WK4xYQM1jf2pT+3PP5Eel8CZebuOOx/dE/13jU0E6AxL0pAcJDJ3Lk0i6k9Yn6O68QCk cdGebzIU1LxcHceCNlR7z/j8nCQrrrjjYhieZaJXui7/3To3/+r3gC5eQz3YlIy+XQEu qhZFazVCS8irvXCF1UcITSdGV67M9kbUlrxRYE8ze8FVRxaZD+j1S7GopgTcFug5NdTV eXoQ== X-Gm-Message-State: AOAM533vwVQjm2GveJz/xB38KMdSSZSbO1opdc7xOlGgqnZ05aLtjhWp TMKiTIfnDNh3Ugp/hRZC2kyOXMDndYrIo/GMPC7l9ODjupOx05Epf0ug9DT5CC4Qnnb5W4NRmJu 1buoUpXE+Mng= X-Received: by 2002:ac8:5f0d:: with SMTP id x13mr5690597qta.69.1623942644892; Thu, 17 Jun 2021 08:10:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwPeCcPHmIoclQ5CoZp42sKvMmfN4bqlPekaRMFGmhUVHBfdgF/PKrLkJJ85SfMn6DWbu99yg== X-Received: by 2002:ac8:5f0d:: with SMTP id x13mr5690559qta.69.1623942644656; Thu, 17 Jun 2021 08:10:44 -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 d85sm1955010qkg.84.2021.06.17.08.10.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Jun 2021 08:10:44 -0700 (PDT) Date: Thu, 17 Jun 2021 11:10:42 -0400 From: Peter Xu To: Alistair Popple Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrea Arcangeli , "Kirill A . Shutemov" , Axel Rasmussen , Nadav Amit , Hugh Dickins , Jerome Glisse , Jason Gunthorpe , Andrew Morton , Miaohe Lin , Mike Rapoport , Matthew Wilcox , Mike Kravetz Subject: Re: [PATCH v3 06/27] shmem/userfaultfd: Handle uffd-wp special pte in page fault handler Message-ID: References: <20210527201927.29586-1-peterx@redhat.com> <20210527202122.30739-1-peterx@redhat.com> <5906045.o7RC9TDvkT@nvdebian> MIME-Version: 1.0 In-Reply-To: <5906045.o7RC9TDvkT@nvdebian> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Z72VJIyp; spf=none (imf22.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 976B7C00F787 X-Stat-Signature: fjwr3xr15dmnaceqcpnnbmkbmf8bi1h6 X-HE-Tag: 1623942637-169264 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, Jun 17, 2021 at 06:59:09PM +1000, Alistair Popple wrote: > > +static vm_fault_t do_swap_pte(struct vm_fault *vmf) > > +{ > > + /* > > + * We need to handle special swap ptes before handling ptes that > > + * contain swap entries, always. > > + */ > > + if (unlikely(pte_swp_uffd_wp_special(vmf->orig_pte))) > > + return uffd_wp_handle_special(vmf); > > + > > + return do_swap_page(vmf); > > Probably pretty minor in the scheme of things but why not add this special > case directly to do_swap_page()? Your earlier "shmem/userfaultfd: Handle > uffd-wp special pte in page fault handler" adds this to do_swap_page() > anyway: > > /* > * We should never call do_swap_page upon a swap special pte; just be > * safe to bail out if it happens. > */ > if (WARN_ON_ONCE(is_swap_special_pte(vmf->orig_pte))) > goto out; > > So this patch could instead replace the warning with the call to > uffd_wp_handle_special(), which also means you can remove the extra > pte_unmap_same(vmf) check in uffd_wp_handle_special(). > > I suppose you might have to worry about other callers of do_swap_page(), > but the only other one I could see was __collapse_huge_page_swapin(). > Initially I thought that might be able to trigger the warning here but I > see it checks pte_has_swap_entry() first which should skip it if it finds > the special pte. Yes I wanted to keep the existing caller untouched, and I wanted to keep its semantics too to not bother with the new idea (it turns out do_swap_page should have a history long enough to be beyond when git is introduced to Linux). The other reason is that this series is the first one to introduce the new swap pte which actually does not have a page on the back, so I figured maybe it's good to call the new handler do_swap_pte() (as swap pte can either contain swap entry or not), then we keep do_swap_page() if it's an old typed swap pte (which contains the swap entry). Thanks, -- Peter Xu