Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp7066857ybl; Wed, 15 Jan 2020 15:02:23 -0800 (PST) X-Google-Smtp-Source: APXvYqwh4dsiy3NvXvDMthCfCHPxvF2VZyxuWmAU5UXboElb44m8JKty/XWfRYnwlElhh+7ar+h4 X-Received: by 2002:aca:d610:: with SMTP id n16mr1892090oig.108.1579129343758; Wed, 15 Jan 2020 15:02:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579129343; cv=none; d=google.com; s=arc-20160816; b=SZejzMZN3DoqjPfvO4W4e0BgT6azZ55t/sPG1vST14F27GYt46gdaOsE4lchiJdA4w W99tAVOUcmYeFkyyuATgSpWTax4WqLoJj6QRPj0kEH2a4FMV3ps9eqnR4Lq7wLw6pxQq 4TVt/F9ISIiGSDiJjXHvd2t24FINPQ45ObLxQjFQyMw7yE3oQZY3WIziHoXzo5PB2EbV KozW8QiZzbzTMQWHJ67Qktl3qIx0waO9cbuj8AI+H6ltWErBPs52lBN7Ki9zaUuCEblR cFTRbF+Sty3U7C0nfHNK8fMCiR/Tu2WSR50wfXL6MWkorLBCoxW7hm6RB/OV7JA+N5BB Mpgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:dkim-signature:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=zg/R/7fcAgJd3kTJ0E7rg5d60gxfGzuCPQ4EqY74cnY=; b=XLwSQv07GqdKEuwh2LGL8xtdTHWJE38HFWnbxEqyhaJhgI5dIO4BIDn6TOJJP0LZIA GJ3Zl8njo94Ka+CsQqdiToMSOi2dFA7gaKtATt2TjvOlZESrhfdkWF+8R//jxE029IMP v0KmkPrzsDNDtKHun61Tl+2NXsLTcuVYRKpeuvgaFf8KYN0DgEZTN8kcDSMWuKsEljeo R1MCkYA3ZzVTRyN2qPdVdnBNZIjIsGzvj79Z2rREEeGCg8oJoU5a7rzRYTB6NsQLM1JW 4reJ2WGqigdKTOYxlDAXv9RV47uhnD3BuU3xkk+xn/nB42QH3KaN5AomlIQExwGw6gkN arbw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nvidia.com header.s=n1 header.b=Py+RLeun; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=nvidia.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t12si12066576otq.53.2020.01.15.15.02.11; Wed, 15 Jan 2020 15:02:23 -0800 (PST) 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; dkim=pass header.i=@nvidia.com header.s=n1 header.b=Py+RLeun; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=nvidia.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729239AbgAOWEu (ORCPT + 99 others); Wed, 15 Jan 2020 17:04:50 -0500 Received: from hqnvemgate24.nvidia.com ([216.228.121.143]:18058 "EHLO hqnvemgate24.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726440AbgAOWEu (ORCPT ); Wed, 15 Jan 2020 17:04:50 -0500 Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate24.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Wed, 15 Jan 2020 14:03:53 -0800 Received: from hqmail.nvidia.com ([172.20.161.6]) by hqpgpgate101.nvidia.com (PGP Universal service); Wed, 15 Jan 2020 14:04:49 -0800 X-PGP-Universal: processed; by hqpgpgate101.nvidia.com on Wed, 15 Jan 2020 14:04:49 -0800 Received: from rcampbell-dev.nvidia.com (10.124.1.5) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 15 Jan 2020 22:04:48 +0000 Subject: Re: [PATCH v5 1/2] mm/mmu_notifier: make interval notifier updates safe To: Jason Gunthorpe CC: "linux-rdma@vger.kernel.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "linux-kselftest@vger.kernel.org" , Jerome Glisse , "John Hubbard" , Christoph Hellwig , Andrew Morton , Shuah Khan References: <20191216195733.28353-1-rcampbell@nvidia.com> <20191216195733.28353-2-rcampbell@nvidia.com> <20200109194805.GK20978@mellanox.com> <73225ded-c22d-33f2-ebcb-b9e9aa95266b@nvidia.com> <20200109232548.GO20978@mellanox.com> <633a3dda-d4d7-1233-b290-53d36fb8fda1@nvidia.com> <20200114124523.GM20978@mellanox.com> X-Nvconfidentiality: public From: Ralph Campbell Message-ID: Date: Wed, 15 Jan 2020 14:04:47 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 In-Reply-To: <20200114124523.GM20978@mellanox.com> X-Originating-IP: [10.124.1.5] X-ClientProxiedBy: HQMAIL101.nvidia.com (172.20.187.10) To HQMAIL107.nvidia.com (172.20.187.13) Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1579125833; bh=zg/R/7fcAgJd3kTJ0E7rg5d60gxfGzuCPQ4EqY74cnY=; h=X-PGP-Universal:Subject:To:CC:References:X-Nvconfidentiality:From: Message-ID:Date:User-Agent:MIME-Version:In-Reply-To: X-Originating-IP:X-ClientProxiedBy:Content-Type:Content-Language: Content-Transfer-Encoding; b=Py+RLeunrYDj7F8Wolf23qHH7d1DrtPHrVh74sZya0et6uVxkx6xWOIlCD5UlBPCn Q38ysIPx2s0OiQL53XPVixI5ArOziARZa+5jq0cJkik43L9Gngu78OmEJfDdi9di5/ mTSiJSQBzoYj9y3Pz0CkSYYyTlH225hXoPzlgOIHwtEQJpuRSiWv4qi9/9mvcqbC1h gqs+oQkOfh/ay4mbuuRYIsQ22oAhl+BTw4TVrKddvkPwq6dUECiKDLE58bSvfYQkKZ bvWlQfBdSo4HUl7F4+9UQRMngJzXBCO3hWMcmmrGj76a+MSQSPIojSLkqPILNK5RLW bvJnJjSxTVADA== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/14/20 4:45 AM, Jason Gunthorpe wrote: > On Mon, Jan 13, 2020 at 02:44:52PM -0800, Ralph Campbell wrote: > >> I'm using the device driver lock to serialize find/insert/update/remove >> changes to the interval tree. > > The device driver lock can't really fully serialize this as it doesn't > effect how the intersection lookup runs. > > Jason > Single updates to the interval notifier are atomic due to the struct mmu_notifier_mm spinlock so the issue is with "punching a hole" in the interval. In that case, the existing interval is updated to cover one side of the hole and a new interval is inserted for the other side while holding the driver lock. Since this sequence is done from the invalidate() callback, those two operations will be deferred until the callback returns and any other parallel invalidates complete (which would be serialized on the driver lock). So none of these changes will be visible to the interval tree walks until the last invalidate task calls mn_itree_inv_end() and all the deferred changes are applied atomically while holding the spinlock. I'll make sure to add comments explaining this. But I see your point if this sequence is done outside of the invalidate callback. In that case, if the driver shrank the interval, an invalidate callback for the right hand side could be missed before the insertion of the new interval for the right hand side. I'll explain this in the comments for nouveau_svmm_do_unmap() and dmirror_do_unmap().