From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751683AbdH2UOJ (ORCPT ); Tue, 29 Aug 2017 16:14:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41650 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751219AbdH2UOI (ORCPT ); Tue, 29 Aug 2017 16:14:08 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 42B10C0587F7 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jglisse@redhat.com Date: Tue, 29 Aug 2017 16:14:04 -0400 From: Jerome Glisse To: Linus Torvalds Cc: Linux Kernel Mailing List , linux-mm , Bernhard Held , Adam Borowski , Andrea Arcangeli , Radim =?utf-8?B?S3LEjW3DocWZ?= , Wanpeng Li , Paolo Bonzini , Takashi Iwai , Nadav Amit , Mike Galbraith , "Kirill A . Shutemov" , axie , Andrew Morton Subject: Re: [RFC PATCH] mm/rmap: do not call mmu_notifier_invalidate_page() v3 Message-ID: <20170829201404.GF7546@redhat.com> References: <20170829190526.8767-1-jglisse@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 29 Aug 2017 20:14:08 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 29, 2017 at 12:58:45PM -0700, Linus Torvalds wrote: > On Tue, Aug 29, 2017 at 12:16 PM, Linus Torvalds > wrote: > > > > And then you can check if something actually happened by catching the > > *ATOMIC* call to mmu_notifier_invalidate_page(), setting a flag, and > > then doing something blocking at mmu_notifier_invalidate_range_end() > > time. > > > > Maybe. > > Note that now I have looked more at the users, I think we actually > just want to get rid of mmu_notifier_invalidate_page() entirely in > favor of just calling mmu_notifier_invalidate_range_start()/end(). > > Nobody seems to want an atomic version of > mmu_notifier_invalidate_page(), they are perfectly happy just getting > those range_start/end() call instead. > > HOWEVER. > > There do seem to be places (eg powernv/npu-dma.c, iommu/amd_iommu_v2.c > and ommu/intel-svm.c) that want to get the "invalidate_page()" or > "invalidate_range()" calls, but do *not* catch the begin/end() ones. > The "range" calls were for atomic cases, and the "page" call was for > the few places that weren't (but should have been). They seem to do > the same things. > > So just switching from mmu_notifier_invalidate_page() to the > "invalidate_range_start()/end()" pair instead could break those cases. > > But the mmu_notifier_invalidate_range() call has always been atomic, > afaik. It's called from the ptep_clear_flush_notify(), which is > called while holdin gthe ptl lock as far as I can tell. > > So to handle the powernv/npu-dma.c, iommu/amd_iommu_v2.c and > ommu/intel-svm.c correctly, _and_ get he KVM case right, we probably > need to: > > - replace the existing mmu_notifier_invalidate_page() call with > mmu_notifier_invalidate_range(), and make sure it's inside the locked > region (ie fs/dax.c too - actually move it inside the lock) > > - surround the locked region with those > mmu_notifier_invalidate_range_start()/end() calls. > > - get rid of mmu_notifier_invalidate_page() entirely, it had bad > semantics anyway. > > and from all I can tell that should work for everybody. > > But maybe I'm missing something. > So ignore what i just sent, i will rework it toward that direction. I believe you are right. Jérôme