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;
Subject: Re: [PATCH 02/10] mm/hmm: do not erase snapshot when a range is
 invalidated
To:     <jglisse@redhat.com>, <linux-mm@kvack.org>
CC:     <linux-kernel@vger.kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Ralph Campbell <rcampbell@nvidia.com>
References: <20190129165428.3931-1-jglisse@redhat.com>
 <20190129165428.3931-3-jglisse@redhat.com>
From:   John Hubbard <jhubbard@nvidia.com>
Message-ID: <ca5e182d-6b99-0e5d-91ab-175ddc6acd45@nvidia.com>
Date:   Wed, 20 Feb 2019 15:58:40 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <20190129165428.3931-3-jglisse@redhat.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 1/29/19 8:54 AM, jglisse@redhat.com wrote:
> From: J=C3=A9r=C3=B4me Glisse <jglisse@redhat.com>
>=20
> Users of HMM might be using the snapshot information to do
> preparatory step like dma mapping pages to a device before
> checking for invalidation through hmm_vma_range_done() so
> do not erase that information and assume users will do the
> right thing.
>=20
> Signed-off-by: J=C3=A9r=C3=B4me Glisse <jglisse@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Ralph Campbell <rcampbell@nvidia.com>
> Cc: John Hubbard <jhubbard@nvidia.com>
> ---
>   mm/hmm.c | 6 ------
>   1 file changed, 6 deletions(-)
>=20
> diff --git a/mm/hmm.c b/mm/hmm.c
> index b9f384ea15e9..74d69812d6be 100644
> --- a/mm/hmm.c
> +++ b/mm/hmm.c
> @@ -170,16 +170,10 @@ static int hmm_invalidate_range(struct hmm *hmm, bo=
ol device,
>  =20
>   	spin_lock(&hmm->lock);
>   	list_for_each_entry(range, &hmm->ranges, list) {
> -		unsigned long addr, idx, npages;
> -
>   		if (update->end < range->start || update->start >=3D range->end)
>   			continue;
>  =20
>   		range->valid =3D false;
> -		addr =3D max(update->start, range->start);
> -		idx =3D (addr - range->start) >> PAGE_SHIFT;
> -		npages =3D (min(range->end, update->end) - addr) >> PAGE_SHIFT;
> -		memset(&range->pfns[idx], 0, sizeof(*range->pfns) * npages);
>   	}
>   	spin_unlock(&hmm->lock);
>  =20
>=20

Seems harmless to me. I really cannot see how this could cause a problem,
so you can add:

	Reviewed-by: John Hubbard <jhubbard@nvidia.com>

thanks,
--=20
John Hubbard
NVIDIA