Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp9946918ybi; Wed, 24 Jul 2019 12:50:37 -0700 (PDT) X-Google-Smtp-Source: APXvYqxtQmyrXOk1pL48l09/4HiYH9AAfv+B93NjjHzS5KYwyczw9m+tlbW4JxYt8Vzl0cdBgfiB X-Received: by 2002:a17:902:a5c7:: with SMTP id t7mr88584916plq.288.1563997837506; Wed, 24 Jul 2019 12:50:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563997837; cv=none; d=google.com; s=arc-20160816; b=Oi+Koy7s6IjxtiiWCJFfT29hIUEtcLypV9hlBb8Owcf9xFEI2yZVOjC1qP2xbHhTle 85zCjMLSr1bW53iWaAr0QV1fqMzTmQK/YIFTEgPncROC3DJ33Nv/gnVIAK5CHJyVS6Sj uEjpmxQO30bNE6DsdikriJIIVFVoL0kbioszt0dfMfYl+PJjlfVpFp5G3c3VvL5flDMG 9CQh66BFY2RnYe6k9OnEYhBZLq0ZrXNOUViSpdpG/HhCR3dVvIUdsx5d8USXoNs1Zcsj EqlSdoFWCjqTs+Ud8R8goZxj1mOqFaY3HorWdwvTT1yjdT8NWqLyhS9M6mLy9mds+ENQ ppMA== 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=7Mw9NbtoiZQZJOpXdyhGv2HIjy5nvJ4CnKHyPITeaDI=; b=j9uNBAqrxn6D7nTYDgTaaEwGE4P3XPlTodSp9jPfQZjHOdEru2qlFJlGQ9T95o0dWx gfvIVuFmGUiAboJEnIudWYHLziDUSP0Uv81dXq8T5ntda1fBxlN5Gm9wLnAdJA1bodSh /5G9MN6Sg1QSM2L57z7hcwAQzUXfRg4KnUjI/wHzNSNp2hkLeUMwfHnSHWFbX1HhphAN nuQjpQTeMSpUAJgbYJyT3sgZTmt8Vidp5n0GznOz66wsRyLYFukWc4ImDMI/3GKrq3fz iLHvwN+5TgX4HnDotakZ2QDtZgcQouvmQRwUTlmw/ABQ6u51mRu4MQ/6bq7AUvyt8kdE yuVA== 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 i21si4868344pgj.37.2019.07.24.12.50.23; Wed, 24 Jul 2019 12:50:37 -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 S2391472AbfGXTtC (ORCPT + 99 others); Wed, 24 Jul 2019 15:49:02 -0400 Received: from verein.lst.de ([213.95.11.211]:53836 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391456AbfGXTs5 (ORCPT ); Wed, 24 Jul 2019 15:48:57 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id E520F68B20; Wed, 24 Jul 2019 21:48:55 +0200 (CEST) Date: Wed, 24 Jul 2019 21:48:55 +0200 From: Christoph Hellwig To: Jason Gunthorpe Cc: Michal Hocko , Christoph Hellwig , Ralph Campbell , linux-mm@kvack.org, linux-kernel@vger.kernel.org, nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org, =?iso-8859-1?B?Suly9G1l?= Glisse , Ben Skeggs Subject: Re: [PATCH] mm/hmm: replace hmm_update with mmu_notifier_range Message-ID: <20190724194855.GA15029@lst.de> References: <20190723210506.25127-1-rcampbell@nvidia.com> <20190724070553.GA2523@lst.de> <20190724152858.GB28493@ziepe.ca> <20190724175858.GC6410@dhcp22.suse.cz> <20190724180837.GF28493@ziepe.ca> <20190724185617.GE6410@dhcp22.suse.cz> <20190724185910.GF6410@dhcp22.suse.cz> <20190724192155.GG28493@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190724192155.GG28493@ziepe.ca> 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 Wed, Jul 24, 2019 at 04:21:55PM -0300, Jason Gunthorpe wrote: > If we change the register to keep the hlist sorted by address then we > can do a targetted 'undo' of past starts terminated by address > less-than comparison of the first failing struct mmu_notifier. > > It relies on the fact that rcu is only used to remove items, the list > adds are all protected by mm locks, and the number of mmu notifiers is > very small. > > This seems workable and does not need more driver review/update... > > However, hmm's implementation still needs more fixing. Can we take one step back, please? The only reason why drivers implement both ->invalidate_range_start and ->invalidate_range_end and expect them to be called paired is to keep some form of counter of active invalidation "sections". So instead of doctoring around undo schemes the only sane answer is to take such a counter into the core VM code instead of having each driver struggle with it.