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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5E2F4C433F5 for ; Mon, 15 Nov 2021 16:49:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B154761AFB for ; Mon, 15 Nov 2021 16:49:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org B154761AFB Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 456CF6B007B; Mon, 15 Nov 2021 11:49:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4067D6B007D; Mon, 15 Nov 2021 11:49:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2A7226B007E; Mon, 15 Nov 2021 11:49:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0063.hostedemail.com [216.40.44.63]) by kanga.kvack.org (Postfix) with ESMTP id 17CBE6B007B for ; Mon, 15 Nov 2021 11:49:12 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id C553D84A21 for ; Mon, 15 Nov 2021 16:49:11 +0000 (UTC) X-FDA: 78811749660.27.9D662C1 Received: from mail-qk1-f172.google.com (mail-qk1-f172.google.com [209.85.222.172]) by imf31.hostedemail.com (Postfix) with ESMTP id 0149C105233D for ; Mon, 15 Nov 2021 16:48:53 +0000 (UTC) Received: by mail-qk1-f172.google.com with SMTP id 193so17478156qkh.10 for ; Mon, 15 Nov 2021 08:49:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=l+DuSZ4CW3uL8ZGrV5XvM1KJZzBkYZnjOzvV75YmFLo=; b=Ay5N0s8W4b7VWIRp7+IGY+vcj52iXCNMABiaFI4BwZnlyhEKyCJAC4k8Hx+Ot61u50 4uxq2AvK8wylxaMUu8r+m6V3DG4HIyQ/H9RgawG6AZyRjrl7HC2vYrdzquwY089O1yB+ bnhD1uwhOj1aKSdRi+WIkTst+lgYZpniNkKfm8SWcV7PUyLorigOKmIsTArLChwUwjH+ dEw23mfdG5N3GpLCSuw7pDL22zWmw6CoxtMTa1hhP2ABh7FpLTgMagIsBk14IEIXlskz sK2nWz+EgH49hitnef3sBsxKao5ga2fS5HU8laCGmr+Gm2sgulNMCYf+eTjr1IBh/cNb T1+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=l+DuSZ4CW3uL8ZGrV5XvM1KJZzBkYZnjOzvV75YmFLo=; b=J9jr3LTN9xqCOkCpv3FOch2JsAPf55h0//q4XW/DTAEwewBOlHiV2R0sLRsWYu6K+g c57gKxrr/yYDhmf2TZ7MYCKfRfElOqfa6yUUF+DeXzT/wuCicoPXLHxUEEk5RoIbu5mb N7DJbEGcTaMG7am7yTSU2SJKl8DpU4aLV5+uYzVfS2DyxFvCw4dt9Wj2TiJ0DQUlpe5T JyWqJyAMejBWe6Uj2gfVPBo5F2hes8q8idwCqfZZQGdlTkH6SYFb/IbQ1d18tfxesZ2y cm7YqRJP8XNx4ZNlYnITYiItISy9P6DXN/Ni0HuK6AwZB6Hvkw1Mfa/1hrO6CoJeDzk/ TTaw== X-Gm-Message-State: AOAM531S6bf77zXzzV53pVL6+u0clxDBTNZgg1O3HpjtWyAtaH7j4izZ RdlNCRwhRDLEoNSVINGbePEoFA== X-Google-Smtp-Source: ABdhPJz+ALQX7Ix+Apg+9TYbsDdiwwHHM1jer6yDEsam6jfbWC1D5oVKN/IAmZrKG8fm3LwKH5O1dA== X-Received: by 2002:a05:620a:288c:: with SMTP id j12mr317315qkp.103.1636994950666; Mon, 15 Nov 2021 08:49:10 -0800 (PST) Received: from ziepe.ca ([206.223.160.26]) by smtp.gmail.com with ESMTPSA id i16sm3334898qtx.57.2021.11.15.08.49.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Nov 2021 08:49:10 -0800 (PST) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1mmfAL-00A2Er-2M; Mon, 15 Nov 2021 12:49:09 -0400 Date: Mon, 15 Nov 2021 12:49:09 -0400 From: Jason Gunthorpe To: Joao Martins Cc: linux-mm@kvack.org, Dan Williams , Vishal Verma , Dave Jiang , Naoya Horiguchi , Matthew Wilcox , John Hubbard , Jane Chu , Muchun Song , Mike Kravetz , Andrew Morton , Jonathan Corbet , Christoph Hellwig , nvdimm@lists.linux.dev, linux-doc@vger.kernel.org Subject: Re: [PATCH v5 8/8] device-dax: compound devmap support Message-ID: <20211115164909.GF876299@ziepe.ca> References: <20211112150824.11028-1-joao.m.martins@oracle.com> <20211112150824.11028-9-joao.m.martins@oracle.com> <20211112153404.GD876299@ziepe.ca> <01f36268-4010-ecea-fee5-c128dd8bb179@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01f36268-4010-ecea-fee5-c128dd8bb179@oracle.com> Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=ziepe.ca header.s=google header.b=Ay5N0s8W; spf=pass (imf31.hostedemail.com: domain of jgg@ziepe.ca designates 209.85.222.172 as permitted sender) smtp.mailfrom=jgg@ziepe.ca; dmarc=none X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 0149C105233D X-Stat-Signature: 1zggxqmo6er75se4fgcb1oac1b377iuo X-HE-Tag: 1636994933-980690 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 Mon, Nov 15, 2021 at 01:11:32PM +0100, Joao Martins wrote: > On 11/12/21 16:34, Jason Gunthorpe wrote: > > On Fri, Nov 12, 2021 at 04:08:24PM +0100, Joao Martins wrote: > > > >> diff --git a/drivers/dax/device.c b/drivers/dax/device.c > >> index a65c67ab5ee0..0c2ac97d397d 100644 > >> +++ b/drivers/dax/device.c > >> @@ -192,6 +192,42 @@ static vm_fault_t __dev_dax_pud_fault(struct dev_dax *dev_dax, > >> } > >> #endif /* !CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD */ > >> > >> +static void set_page_mapping(struct vm_fault *vmf, pfn_t pfn, > >> + unsigned long fault_size, > >> + struct address_space *f_mapping) > >> +{ > >> + unsigned long i; > >> + pgoff_t pgoff; > >> + > >> + pgoff = linear_page_index(vmf->vma, ALIGN(vmf->address, fault_size)); > >> + > >> + for (i = 0; i < fault_size / PAGE_SIZE; i++) { > >> + struct page *page; > >> + > >> + page = pfn_to_page(pfn_t_to_pfn(pfn) + i); > >> + if (page->mapping) > >> + continue; > >> + page->mapping = f_mapping; > >> + page->index = pgoff + i; > >> + } > >> +} > >> + > >> +static void set_compound_mapping(struct vm_fault *vmf, pfn_t pfn, > >> + unsigned long fault_size, > >> + struct address_space *f_mapping) > >> +{ > >> + struct page *head; > >> + > >> + head = pfn_to_page(pfn_t_to_pfn(pfn)); > >> + head = compound_head(head); > >> + if (head->mapping) > >> + return; > >> + > >> + head->mapping = f_mapping; > >> + head->index = linear_page_index(vmf->vma, > >> + ALIGN(vmf->address, fault_size)); > >> +} > > > > Should this stuff be setup before doing vmf_insert_pfn_XX? > > > > Interestingly filesystem-dax does this, but not device-dax. I think it may be a bug ? > set_page_mapping/set_compound_mapping() could be moved to before and > then torn down on @rc != VM_FAULT_NOPAGE (failure). I am not sure > what's the benefit in this series.. besides the ordering (that you > hinted below) ? Well, it should probably be fixed in a precursor patch. I think the general idea is that page->mapping/index are stable once the page is published in a PTE? > > In normal cases the page should be returned in the vmf and populated > > to the page tables by the core code after all this is done. > > So I suppose by call sites examples as 'core code' is either hugetlbfs call to > __filemap_add_folio() (on hugetlbfs fault handler), shmem_add_to_page_cache() or > anon-equivalent. I was talking more about the normal page insertion flow which is done by setting vmf->page and then returning. finish_fault() will install the PTE If this is the best way then I would expect some future where maybe there is a vmf->folio and finish_fault() will install a PUD/PMD/PTE and we don't call vmf_insert_pfnxx in DAX. Jason