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=-8.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 3BF7DCA9EAF for ; Tue, 22 Oct 2019 02:45:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B212F2086D for ; Tue, 22 Oct 2019 02:45:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="QY8n8SMr" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B212F2086D 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 1D57E6B0003; Mon, 21 Oct 2019 22:45:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 185E56B0006; Mon, 21 Oct 2019 22:45:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 09CD06B0007; Mon, 21 Oct 2019 22:45:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0046.hostedemail.com [216.40.44.46]) by kanga.kvack.org (Postfix) with ESMTP id DC9676B0003 for ; Mon, 21 Oct 2019 22:45:56 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id 427B08249980 for ; Tue, 22 Oct 2019 02:45:56 +0000 (UTC) X-FDA: 76069880712.27.drum99_33cc7b7711037 X-HE-Tag: drum99_33cc7b7711037 X-Filterd-Recvd-Size: 5044 Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by imf06.hostedemail.com (Postfix) with ESMTP for ; Tue, 22 Oct 2019 02:45:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1571712355; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VdtkIFyiHAOI13mkQxpBz9LE01qOPeMsARcYeNx52wY=; b=QY8n8SMrKe6LUbj0zEkClZJrJ+ekFFh505JzHp7+jdiny9SKy756V7/++Gd3YdN3IA4/cS PMu/uupWPU91fNxQA2PsEigUudhzYplKJbKWAQOmNrNmKAmZJfzNWpbsYX7yq9Xf141QOR S29a1o0g6laxSNOGrSPrlJDHIo4ty9Y= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-223-bD-UMq-nO-m9-vaopSnFJg-1; Mon, 21 Oct 2019 22:45:53 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3CBB580183E; Tue, 22 Oct 2019 02:45:52 +0000 (UTC) Received: from redhat.com (ovpn-120-88.rdu2.redhat.com [10.10.120.88]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3578D60A35; Tue, 22 Oct 2019 02:45:51 +0000 (UTC) Date: Mon, 21 Oct 2019 22:45:49 -0400 From: Jerome Glisse To: Ralph Campbell Cc: John Hubbard , Christoph Hellwig , Jason Gunthorpe , linux-rdma@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2 2/3] mm/hmm: allow snapshot of the special zero page Message-ID: <20191022024549.GA4347@redhat.com> References: <20191015204814.30099-1-rcampbell@nvidia.com> <20191015204814.30099-3-rcampbell@nvidia.com> <20191021184927.GG3177@redhat.com> <95fa45cf-a2ce-fab8-588d-8d806124aef3@nvidia.com> MIME-Version: 1.0 In-Reply-To: <95fa45cf-a2ce-fab8-588d-8d806124aef3@nvidia.com> User-Agent: Mutt/1.12.1 (2019-06-15) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-MC-Unique: bD-UMq-nO-m9-vaopSnFJg-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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, Oct 21, 2019 at 01:54:15PM -0700, Ralph Campbell wrote: >=20 > On 10/21/19 11:49 AM, Jerome Glisse wrote: > > On Tue, Oct 15, 2019 at 01:48:13PM -0700, Ralph Campbell wrote: > > > Allow hmm_range_fault() to return success (0) when the CPU pagetable > > > entry points to the special shared zero page. > > > The caller can then handle the zero page by possibly clearing device > > > private memory instead of DMAing a zero page. > >=20 > > I do not understand why you are talking about DMA. GPU can work > > on main memory and migrating to GPU memory is optional and should > > not involve this function at all. >=20 > Good point. This is the device accessing the zero page over PCIe > or another bus, not migrating a zero page to device private memory. > I'll update the wording. >=20 > > >=20 > > > Signed-off-by: Ralph Campbell > > > Reviewed-by: Christoph Hellwig > > > Cc: "J=E9r=F4me Glisse" > > > Cc: Jason Gunthorpe > >=20 > > NAK please keep semantic or change it fully. See the alternative > > below. > >=20 > > > --- > > > mm/hmm.c | 4 +++- > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > >=20 > > > diff --git a/mm/hmm.c b/mm/hmm.c > > > index 5df0dbf77e89..f62b119722a3 100644 > > > --- a/mm/hmm.c > > > +++ b/mm/hmm.c > > > @@ -530,7 +530,9 @@ static int hmm_vma_handle_pte(struct mm_walk *wal= k, unsigned long addr, > > > =09=09=09return -EBUSY; > > > =09} else if (IS_ENABLED(CONFIG_ARCH_HAS_PTE_SPECIAL) && pte_specia= l(pte)) { > > > =09=09*pfn =3D range->values[HMM_PFN_SPECIAL]; > > > -=09=09return -EFAULT; > > > +=09=09if (!is_zero_pfn(pte_pfn(pte))) > > > +=09=09=09return -EFAULT; > > > +=09=09return 0; > >=20 > > An acceptable change would be to turn the branch into: > > =09} else if (IS_ENABLED(CONFIG_ARCH_HAS_PTE_SPECIAL) && pte_special(pt= e)) { > > =09=09if (!is_zero_pfn(pte_pfn(pte))) { > > =09=09=09*pfn =3D range->values[HMM_PFN_SPECIAL]; > > =09=09=09return -EFAULT; > > =09=09} > > =09=09/* Fall-through for zero pfn (if write was needed the above > > =09=09 * hmm_pte_need_faul() would had catched it). > > =09=09 */ > > =09} > >=20 >=20 > Except this will return the zero pfn with no indication that it is specia= l > (i.e., doesn't have a struct page). That is fine, the device driver should not do anything with it ie if the device driver wanted to write then the write fault test would return true and it would fault. Note that driver should not dereference the struct page. Cheers, J=E9r=F4me