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.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED, USER_AGENT_MUTT autolearn=unavailable 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 C1BABC10F11 for ; Wed, 10 Apr 2019 23:42:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8FF80217D4 for ; Wed, 10 Apr 2019 23:42:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726761AbfDJXmD (ORCPT ); Wed, 10 Apr 2019 19:42:03 -0400 Received: from mga12.intel.com ([192.55.52.136]:15324 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726014AbfDJXmD (ORCPT ); Wed, 10 Apr 2019 19:42:03 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Apr 2019 16:42:02 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,335,1549958400"; d="scan'208";a="134714856" Received: from iweiny-desk2.sc.intel.com ([10.3.52.157]) by orsmga006.jf.intel.com with ESMTP; 10 Apr 2019 16:42:00 -0700 Date: Wed, 10 Apr 2019 16:41:57 -0700 From: Ira Weiny To: jglisse@redhat.com Cc: linux-kernel@vger.kernel.org, Andrew Morton , linux-mm@kvack.org, Christian =?iso-8859-1?Q?K=F6nig?= , Joonas Lahtinen , Jani Nikula , Rodrigo Vivi , Jan Kara , Andrea Arcangeli , Peter Xu , Felix Kuehling , Jason Gunthorpe , Ross Zwisler , Dan Williams , Paolo Bonzini , Radim =?utf-8?B?S3LEjW3DocWZ?= , Michal Hocko , Ralph Campbell , John Hubbard , kvm@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-rdma@vger.kernel.org, Arnd Bergmann Subject: Re: [PATCH v6 7/8] mm/mmu_notifier: pass down vma and reasons why mmu notifier is happening v2 Message-ID: <20190410234124.GE22989@iweiny-DESK2.sc.intel.com> References: <20190326164747.24405-1-jglisse@redhat.com> <20190326164747.24405-8-jglisse@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190326164747.24405-8-jglisse@redhat.com> User-Agent: Mutt/1.11.1 (2018-12-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 26, 2019 at 12:47:46PM -0400, Jerome Glisse wrote: > From: Jérôme Glisse > > CPU page table update can happens for many reasons, not only as a result > of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also > as a result of kernel activities (memory compression, reclaim, migration, > ...). > > Users of mmu notifier API track changes to the CPU page table and take > specific action for them. While current API only provide range of virtual > address affected by the change, not why the changes is happening > > This patch is just passing down the new informations by adding it to the > mmu_notifier_range structure. > > Changes since v1: > - Initialize flags field from mmu_notifier_range_init() arguments > > Signed-off-by: Jérôme Glisse > Cc: Andrew Morton > Cc: linux-mm@kvack.org > Cc: Christian König > Cc: Joonas Lahtinen > Cc: Jani Nikula > Cc: Rodrigo Vivi > Cc: Jan Kara > Cc: Andrea Arcangeli > Cc: Peter Xu > Cc: Felix Kuehling > Cc: Jason Gunthorpe > Cc: Ross Zwisler > Cc: Dan Williams > Cc: Paolo Bonzini > Cc: Radim Krčmář > Cc: Michal Hocko > Cc: Christian Koenig > Cc: Ralph Campbell > Cc: John Hubbard > Cc: kvm@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > Cc: linux-rdma@vger.kernel.org > Cc: Arnd Bergmann > --- > include/linux/mmu_notifier.h | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h > index 62f94cd85455..0379956fff23 100644 > --- a/include/linux/mmu_notifier.h > +++ b/include/linux/mmu_notifier.h > @@ -58,10 +58,12 @@ struct mmu_notifier_mm { > #define MMU_NOTIFIER_RANGE_BLOCKABLE (1 << 0) > > struct mmu_notifier_range { > + struct vm_area_struct *vma; > struct mm_struct *mm; > unsigned long start; > unsigned long end; > unsigned flags; > + enum mmu_notifier_event event; > }; > > struct mmu_notifier_ops { > @@ -363,10 +365,12 @@ static inline void mmu_notifier_range_init(struct mmu_notifier_range *range, > unsigned long start, > unsigned long end) > { > + range->vma = vma; > + range->event = event; > range->mm = mm; > range->start = start; > range->end = end; > - range->flags = 0; > + range->flags = flags; Which of the "user patch sets" uses the new flags? I'm not seeing that user yet. In general I don't see anything wrong with the series and I like the idea of telling drivers why the invalidate has fired. But is the flags a future feature? For the series: Reviewed-by: Ira Weiny Ira > } > > #define ptep_clear_flush_young_notify(__vma, __address, __ptep) \ > -- > 2.20.1 >