Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 28 Jan 2021 09:44:15 +1000
From:   Nicholas Piggin <npiggin@gmail.com>
Subject: Re: [PATCH 2/5] kernel/dma: remove unnecessary unmap_kernel_range
To:     Christoph Hellwig <hch@lst.de>,
        Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
        linux-mm@kvack.org, Robin Murphy <robin.murphy@arm.com>
References: <20210126045404.2492588-1-npiggin@gmail.com>
        <20210126045404.2492588-3-npiggin@gmail.com>
        <YBCS7toITTwP04aK@Konrads-MacBook-Pro.local> <20210127071059.GA21133@lst.de>
In-Reply-To: <20210127071059.GA21133@lst.de>
MIME-Version: 1.0
Message-Id: <1611790740.civn6atbwp.astroid@bobo.none>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Excerpts from Christoph Hellwig's message of January 27, 2021 5:10 pm:
> On Tue, Jan 26, 2021 at 05:08:46PM -0500, Konrad Rzeszutek Wilk wrote:
>> On Tue, Jan 26, 2021 at 02:54:01PM +1000, Nicholas Piggin wrote:
>> > vunmap will remove ptes.
>>=20
>> Should there be some ASSERT after the vunmap to make sure that is the
>> case?=20
>=20
> Not really.  removing the PTEs is the whole point of vunmap.  Everything
> else is just house keeping.

Agree. I did double check this and wrote a quick test to check ptes were=20
there before the vunmap and cleared after, just to make sure I didn't=20
make a silly mistake with the patch. But in general drivers should be=20
able to trust code behind the API call will do the right thing. Such=20
assertions should go in the vunmap() implementation as appropriate.

Thanks,
Nick