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;
From:   Liam Howlett <liam.howlett@oracle.com>
To:     Michel Lespinasse <michel@lespinasse.org>
CC:     "maple-tree@lists.infradead.org" <maple-tree@lists.infradead.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Song Liu <songliubraving@fb.com>,
        Davidlohr Bueso <dave@stgolabs.net>,
        "Paul E . McKenney" <paulmck@kernel.org>,
        Matthew Wilcox <willy@infradead.org>,
        Laurent Dufour <ldufour@linux.ibm.com>,
        David Rientjes <rientjes@google.com>,
        Axel Rasmussen <axelrasmussen@google.com>,
        Suren Baghdasaryan <surenb@google.com>,
        Vlastimil Babka <vbabka@suse.cz>,
        Rik van Riel <riel@surriel.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Michel Lespinasse <walken.cr@gmail.com>
Subject: Re: [PATCH 01/94] mm: Add vma_lookup()
Thread-Topic: [PATCH 01/94] mm: Add vma_lookup()
Thread-Index: AQHXPEQmA9/hNjlhF0O1j8k1xuPy8qrOFnOAgAPeL4A=
Date:   Mon, 3 May 2021 16:08:47 +0000
Message-ID: <20210503160841.2juynuimujnaajad@revolver>
References: <20210428153542.2814175-1-Liam.Howlett@Oracle.com>
 <20210428153542.2814175-2-Liam.Howlett@Oracle.com>
 <20210501050441.GB5188@lespinasse.org>
In-Reply-To: <20210501050441.GB5188@lespinasse.org>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <C31D3A8CAA64674685EA987E3E09C4B7@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 927b1c9d-a469-4b78-b9e9-08d90e4dbbc5
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2021 16:08:47.3824
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: rH6BcUNTTgzZHXwcZvOqOcCkxAYg9akR/LO9GgtzwJ87Xjds4nrwm+RlY7a7wzORypctefxM2k4JoTgSFaW5Pg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR10MB4481
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9973 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxlogscore=999
 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 adultscore=0
 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2104060000 definitions=main-2105030107
X-Proofpoint-GUID: _q0Afz_laPpgdnUgt6wikDrE3Oznmd45
X-Proofpoint-ORIG-GUID: _q0Afz_laPpgdnUgt6wikDrE3Oznmd45
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9973 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 mlxlogscore=999
 suspectscore=0 priorityscore=1501 phishscore=0 malwarescore=0
 impostorscore=0 clxscore=1015 bulkscore=0 spamscore=0 adultscore=0
 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2104060000 definitions=main-2105030107
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

* Michel Lespinasse <michel@lespinasse.org> [210501 01:04]:
> On Wed, Apr 28, 2021 at 03:35:43PM +0000, Liam Howlett wrote:
> > Many places in the kernel use find_vma() to get a vma and then check th=
e
> > start address of the vma to ensure the next vma was not returned.
> >=20
> > Other places use the find_vma_intersection() call with add, addr + 1 as
> > the range; looking for just the vma at a specific address.
> >=20
> > The third use of find_vma() is by developers who do not know that the
> > function starts searching at the provided address upwards for the next
> > vma.  This results in a bug that is often overlooked for a long time.
> >=20
> > Adding the new vma_lookup() function will allow for cleaner code by
> > removing the find_vma() calls which check limits, making
> > find_vma_intersection() calls of a single address to be shorter, and
> > potentially reduce the incorrect uses of find_vma().
> >=20
> > Signed-off-by: Liam R. Howlett <Liam.Howlett@Oracle.com>
>=20
> This seems like a good API to have, and I agree it's less error prone tha=
n
> having every caller check the vma->vm_start address.
>=20
> Minor nitpick, I would prefer if the implementation used find_vma()
> and then checked the vma->vm_start address - I don't like using [i, i+1)
> intervals to implement stabbing queries.

Okay, I will make that change.

>=20
> But other than that, I think this (and the other patches adding
> corresponding call sites) is safe for merging.
>=20

Thanks,
Liam=