Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp2301976ybd; Thu, 27 Jun 2019 10:03:50 -0700 (PDT) X-Google-Smtp-Source: APXvYqxBj5Jx2ERMkTrRSe7NjNLcY/lVsqPQdUZ4Y2KQ9XsN8VaHhOa7KtcF7rKqTB3mVhhORhuU X-Received: by 2002:a63:d756:: with SMTP id w22mr4640763pgi.156.1561655030194; Thu, 27 Jun 2019 10:03:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561655030; cv=none; d=google.com; s=arc-20160816; b=Qf9TwAERivtnm3k7qIk7TxMazDY/y7df8rgM9Zw6zAHVUvA5dcW+ouanUw4+5UyU/V e5KIRzlkhslMSImNrmhgf9yNeiEfCN3otT73pIjN2umxbvijmxmhmd98RyGQdwQr3N6t 4lm05S1pkDTsLXhh3JGg5jSaLLepLCYLi06S3lUF2zKx0wMJILoowZ1ZKw4DbG6gUG5w rycLqcWuQboQ8Q3Mn19ZBBYQSRjvkVvV+XNo3mjXT0dwM5cVUgHuHTWymEiT+6OkmxqM M9qAZ91e+PJvILBLX86q5kXiEeT2GlSYY3UF2qxiq/B/8EUrlMLmD4qWqqR0GjGHkyin +//g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=xU/whg26sgUfF+Dq0O8Uj10RgLXDjiGOor0v0A6Ejxg=; b=G+b+iY1T1muI000hqYCpLzDFH9T9WpYAklQjRTBaM3iJ1DeXCgN/YY19m/NmoykG7K /C6w2dJKCuFSP/VBdMb9UNwEKdOhBc+9vXGu0BYHqh/7pWaaQSM3NNkBkRBiiMwFvZEO JQqUqIwvAWONuqHaZYennNOeovreGAmHq3P/PgchSyWN8LYN9BPxax4LM2XOTTc7WA45 RQLyfvq/YMu0GBOKs0QyKRZMmkwOI/cnAmutYUga0CACJ5yiM84wTyM2n+vGxHQ08qnP qlKVCwpwfn8FbmSmY9R5tvjXDvBRCOxbsQxAifmJI+1G44cwAF9xLmm38GyKtRahVx8V S32g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f89si62208pje.50.2019.06.27.10.03.24; Thu, 27 Jun 2019 10:03:50 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726524AbfF0RBv (ORCPT + 99 others); Thu, 27 Jun 2019 13:01:51 -0400 Received: from verein.lst.de ([213.95.11.210]:40323 "EHLO newverein.lst.de" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726315AbfF0RBv (ORCPT ); Thu, 27 Jun 2019 13:01:51 -0400 Received: by newverein.lst.de (Postfix, from userid 2407) id 4B57968C4E; Thu, 27 Jun 2019 18:53:49 +0200 (CEST) Date: Thu, 27 Jun 2019 18:53:49 +0200 From: Christoph Hellwig To: Jason Gunthorpe Cc: Christoph Hellwig , Dan Williams , =?iso-8859-1?B?Suly9G1l?= Glisse , Ben Skeggs , "linux-mm@kvack.org" , "nouveau@lists.freedesktop.org" , "dri-devel@lists.freedesktop.org" , "linux-nvdimm@lists.01.org" , "linux-pci@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Ralph Campbell Subject: Re: [PATCH 12/25] memremap: add a migrate_to_ram method to struct dev_pagemap_ops Message-ID: <20190627165349.GB10652@lst.de> References: <20190626122724.13313-1-hch@lst.de> <20190626122724.13313-13-hch@lst.de> <20190627162439.GD9499@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190627162439.GD9499@mellanox.com> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 27, 2019 at 04:29:45PM +0000, Jason Gunthorpe wrote: > I'ver heard there are some other use models for fault() here beyond > migrate to ram, but we can rename it if we ever see them. Well, it absolutely needs to migrate to some piece of addressable and coherent memory, so ram might be a nice shortcut for that. > > +static vm_fault_t hmm_devmem_migrate_to_ram(struct vm_fault *vmf) > > { > > - struct hmm_devmem *devmem = page->pgmap->data; > > + struct hmm_devmem *devmem = vmf->page->pgmap->data; > > > > - return devmem->ops->fault(devmem, vma, addr, page, flags, pmdp); > > + return devmem->ops->fault(devmem, vmf->vma, vmf->address, vmf->page, > > + vmf->flags, vmf->pmd); > > } > > Next cycle we should probably rename this fault to migrate_to_ram as > well and pass in the vmf.. That ->fault op goes away entirely in one of the next patches in the series.