Received: by 2002:a05:7412:a9a3:b0:f9:93eb:408e with SMTP id o35csp12280rdh; Wed, 20 Dec 2023 20:40:36 -0800 (PST) X-Google-Smtp-Source: AGHT+IHf5dmfZ+PtUelilwS1NB4sQw20ru5750a8itQqcQaLgKFgr0YDkimiRMvkWQJEWW6oO++d X-Received: by 2002:a17:906:7486:b0:a23:74e1:da9e with SMTP id e6-20020a170906748600b00a2374e1da9emr2014593ejl.53.1703133636360; Wed, 20 Dec 2023 20:40:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703133636; cv=none; d=google.com; s=arc-20160816; b=mBIYqsaX7m8BMhdDHy4qsegh3SOCQKUSojZzIwhgxcNKcDVTszoUeNPPcqCjHv7siY XsXfLpSPZetUzOhR3NetK/fyLorZgsDan841IgGrqZDxBVlSE1M91nx1DivmkYD6u97k OXcTuqmh3L3D7TcS0S6/vnvicvKEJZXaDH7M2Squ6EYRoL+8pwRUZrufG0XC4x0tei/Z tLXAk2b/m5vPIC+lA5CnS+McIa/sd5t8Gm6ULQH/oC8UaRF3OZLNQFaX4QDWrhal7NE+ FqpWe1EuUE8xMh+MB12NSQz2xDWuRkSPoIPIilL9pJYBBEVtTfdOw9S4e+8yvIqqAb0q NjVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=2zC04biBcA1BX1DOBH2ATIvTR6mxcapHZpr9s+7+ipo=; fh=nl1WOPtpgLTDn7jj2iUo+PQab59As1DE1VCzg2MI498=; b=BHydUYA87Fv11MryksaG3JCatSUnThRHTGm/KM+2VZbqt6CiqAuKm3V7BjmDlDXHXQ 53NRIcXThXlSD9fgXfUb+U2DI4DCViegKebyi2Q0CfO/GTvD8JcJZvL19g86m0VTxRnc pOQAS7mmlMM5kzR08di23O1lQs3qID0ewhgpgREdBth/bJLEePVsPZ1SBrQqdibbuthu ahheF1dOpY2Lwu7kH7V8Pn2OzBaHCA+jtry/rhCwmUiJRs9AesYSmwWYQxDHx/zz3zsV fCeHBR0eij5RZWvKuVNwR/KF+LLGZuXBq0LC4HSyN28QVOepMKI4bAgyTG0U7B8PQPgr IsFQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b="gX/kDnjR"; spf=pass (google.com: domain of linux-kernel+bounces-7842-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-7842-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id s8-20020a170906c30800b00a233549825asi447252ejz.974.2023.12.20.20.40.36 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Dec 2023 20:40:36 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-7842-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b="gX/kDnjR"; spf=pass (google.com: domain of linux-kernel+bounces-7842-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-7842-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 204D41F24608 for ; Thu, 21 Dec 2023 04:40:36 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id E740D8F4F; Thu, 21 Dec 2023 04:40:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="gX/kDnjR" X-Original-To: linux-kernel@vger.kernel.org Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C398E8BED for ; Thu, 21 Dec 2023 04:40:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=2zC04biBcA1BX1DOBH2ATIvTR6mxcapHZpr9s+7+ipo=; b=gX/kDnjRM5qvuJs5UqsVh1DEtN 59jtdoe8/wx6hHnhYxenSkG/dlM4FPFkW8g8HlOfkiMDAez1J303b9KPPZFrna7XzovY1ZmxA0aaB E+T/9pBzZXV+fcXMK8foeekpP9JrqktBKFbhROlMJM/lyLd7sAIG76ZeVlPnyrCR5A+z2nLLFQpGN Idx3KrYx+CLABup+FV/6m4zupf+qrvqNYbSdVsDDwfb5Th+cAYnxkJsmONyqo418VBrZvhyCqg6TM 36OVmzIuQB4AkGl7GTBVSoWdQm2KORjrLm7VveF3sf+5U2zAvXVyhoE/wg7wcsHJKPCGOpbhrfmN8 eS3nt3JA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1rGAr9-004fI2-QE; Thu, 21 Dec 2023 04:40:23 +0000 Date: Thu, 21 Dec 2023 04:40:23 +0000 From: Matthew Wilcox To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Hugh Dickins , Ryan Roberts , Yin Fengwei , Mike Kravetz , Muchun Song , Peter Xu Subject: Re: [PATCH v2 04/40] mm/rmap: introduce and use hugetlb_try_dup_anon_rmap() Message-ID: References: <20231220224504.646757-1-david@redhat.com> <20231220224504.646757-5-david@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231220224504.646757-5-david@redhat.com> On Wed, Dec 20, 2023 at 11:44:28PM +0100, David Hildenbrand wrote: > hugetlb rmap handling differs quite a lot from "ordinary" rmap code. > For example, hugetlb currently only supports entire mappings, and treats > any mapping as mapped using a single "logical PTE". Let's move it out > of the way so we can overhaul our "ordinary" rmap. > implementation/interface. > > So let's introduce and use hugetlb_try_dup_anon_rmap() to make all > hugetlb handling use dedicated hugetlb_* rmap functions. > > Add sanity checks that we end up with the right folios in the right > functions. > > Note that is_device_private_page() does not apply to hugetlb. > > Reviewed-by: Yin Fengwei > Reviewed-by: Ryan Roberts > Signed-off-by: David Hildenbrand Reviewed-by: Matthew Wilcox (Oracle) > +static inline bool folio_needs_cow_for_dma(struct vm_area_struct *vma, > + struct folio *folio) I particularly like it that you introduced this. > +static inline int hugetlb_try_dup_anon_rmap(struct folio *folio, > + struct vm_area_struct *vma) > +{ > + VM_WARN_ON_FOLIO(!folio_test_hugetlb(folio), folio); > + VM_WARN_ON_FOLIO(!folio_test_anon(folio), folio); > + > + if (PageAnonExclusive(&folio->page)) { I wonder if we need a folio_test_hugetlb_anon_exclusive() to make this a little more ergonomic? > + if (unlikely(folio_needs_cow_for_dma(vma, folio))) > + return -EBUSY; > + ClearPageAnonExclusive(&folio->page); ... and set/clear variants.