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=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 7970FC3A589 for ; Thu, 15 Aug 2019 20:51:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4FFD620578 for ; Thu, 15 Aug 2019 20:51:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732850AbfHOUvg (ORCPT ); Thu, 15 Aug 2019 16:51:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49862 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730540AbfHOUvg (ORCPT ); Thu, 15 Aug 2019 16:51:36 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CD57286663; Thu, 15 Aug 2019 20:51:35 +0000 (UTC) Received: from redhat.com (unknown [10.20.6.178]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C77D017B64; Thu, 15 Aug 2019 20:51:34 +0000 (UTC) Date: Thu, 15 Aug 2019 16:51:33 -0400 From: Jerome Glisse To: Jason Gunthorpe Cc: Dan Williams , Christoph Hellwig , Ben Skeggs , Felix Kuehling , Ralph Campbell , "linux-mm@kvack.org" , "nouveau@lists.freedesktop.org" , "dri-devel@lists.freedesktop.org" , "amd-gfx@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk Message-ID: <20190815205132.GC25517@redhat.com> References: <20190814073854.GA27249@lst.de> <20190814132746.GE13756@mellanox.com> <20190815180325.GA4920@redhat.com> <20190815194339.GC9253@redhat.com> <20190815203306.GB25517@redhat.com> <20190815204128.GI22970@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190815204128.GI22970@mellanox.com> User-Agent: Mutt/1.11.3 (2019-02-01) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 15 Aug 2019 20:51:36 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 15, 2019 at 08:41:33PM +0000, Jason Gunthorpe wrote: > On Thu, Aug 15, 2019 at 04:33:06PM -0400, Jerome Glisse wrote: > > > So nor HMM nor driver should dereference the struct page (i do not > > think any iommu driver would either), > > Er, they do technically deref the struct page: > > nouveau_dmem_convert_pfn(struct nouveau_drm *drm, > struct hmm_range *range) > struct page *page; > page = hmm_pfn_to_page(range, range->pfns[i]); > if (!nouveau_dmem_page(drm, page)) { > > > nouveau_dmem_page(struct nouveau_drm *drm, struct page *page) > { > return is_device_private_page(page) && drm->dmem == page_to_dmem(page) > > > Which does touch 'page->pgmap' > > Is this OK without having a get_dev_pagemap() ? > > Noting that the collision-retry scheme doesn't protect anything here > as we can have a concurrent invalidation while doing the above deref. Uh ? How so ? We are not reading the same code i think. My read is that function is call when holding the device lock which exclude any racing mmu notifier from making forward progress and it is also protected by the range so at the time this happens it is safe to dereference the struct page. In this case any way we can update the nouveau_dmem_page() to check that page page->pgmap == the expected pgmap. Cheers, Jérôme