From nobody Wed Apr 1 09:48:04 2026 Received: from sender-pp-o93.zoho.in (sender-pp-o93.zoho.in [103.117.158.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2372C30F7EF for ; Tue, 31 Mar 2026 14:31:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=103.117.158.93 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774967492; cv=pass; b=YsqAFb4ERnOzoHQLoCkL5lbWGGMVomCYgNtblkYJ49gi++Owq1wFb4WhEp7ftHdhzrVoNNyds/z3EHHoPu6Pp/+OiaVVBtpTNhfiqclPGFxYvZlKT+V3cHLQ0ERwkSK9hZOzRKr3bv2PoXCTw0TBM6alE94bydQIvcc7zzXtAa8= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774967492; c=relaxed/simple; bh=rbthQOYb9MnkRTiAq4xfZuBAMSqfiSUQVOYcIx7jg/g=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=MS+1VtwmiAZNtNzvZ4zwIPu1Mp5NYNgpYBWmyJajgHdHIQIXG1mG7dkIbFB2QqMfCxGBJj/yo7y/pDNSj4CwLewNd0qmh5Ty70jkREEJ8kYRrIIPYEuFWwOIcRGAhFR4fjsbVC4WC1kejdskwxMyVTM0OSmEbGm0tj0A8lCuqYg= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=zohomail.in; spf=pass smtp.mailfrom=zohomail.in; dkim=pass (1024-bit key) header.d=zohomail.in header.i=adi.sharma@zohomail.in header.b=oTPjgewB; arc=pass smtp.client-ip=103.117.158.93 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=zohomail.in Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zohomail.in Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=zohomail.in header.i=adi.sharma@zohomail.in header.b="oTPjgewB" ARC-Seal: i=1; a=rsa-sha256; t=1774967445; cv=none; d=zohomail.in; s=zohoarc; b=PR2BOI0WUA/jbhJQoSugMXDrktANluxu9zUXOhjhGawzQnC3UckTjVktO70EJQnYfgVs7aGj/B9IWJ0+HQQer1ItO9kjPlrDCA57bD1D/nA0dd/+cAUxY1ZFmoGi5dKiW6wnGKI8VZW8AR+pyS+FQBIpyJYdmiiyXNnR9VN8R0A= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.in; s=zohoarc; t=1774967445; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; bh=NGshc/UqCbA7iiGIi9F1QT8k5YqCxY0TabFipUM0D5E=; b=FFkSnReCN8BEp19kru1SmBJxFsDJgH/Gk+J+MBmlkAJ1q7M8u/P8yPXH43mA65ny28VGt51DUwkxIlOipe0GCd6DL/SpiZ3iGWiXMykKi/cp/S+lRbnEHtXegUKq7NALMvtPLLQQTSyrL4X4uogXTASU2rEF9uqabEaOcRlvHT8= ARC-Authentication-Results: i=1; mx.zohomail.in; dkim=pass header.i=zohomail.in; spf=pass smtp.mailfrom=adi.sharma@zohomail.in; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1774967445; s=zoho; d=zohomail.in; i=adi.sharma@zohomail.in; h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:MIME-Version:Content-Transfer-Encoding:Reply-To; bh=NGshc/UqCbA7iiGIi9F1QT8k5YqCxY0TabFipUM0D5E=; b=oTPjgewBYhOtOkyBL+NYJtv7YEeThH7kqVgCTxPSD+IXAfYDqARFNo5YN9bw3UVK NcgB+INEzz2o3Kh16N5BVixwG8WbLTUFk7nMsvp2eW1nQtuwDjQREbUBDCPWK6WB48N nmR2emg2xSakv1oXPn8lizcJvOB87dIp2FDi8QE0= Received: by mx.zoho.in with SMTPS id 177496744424821.477018728494045; Tue, 31 Mar 2026 20:00:44 +0530 (IST) From: Aditya Sharma To: linux-mm@kvack.org Cc: akpm@linux-foundation.org, david@kernel.org, ljs@kernel.org, Liam.Howlett@oracle.com, vbabka@kernel.org, rppt@kernel.org, surenb@google.com, mhocko@suse.com, linux-kernel@vger.kernel.org, Aditya Sharma Subject: [PATCH] mm: update stale locking comment in do_anonymous_page() Date: Tue, 31 Mar 2026 19:59:36 +0530 Message-Id: <20260331142936.229667-1-adi.sharma@zohomail.in> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External Content-Type: text/plain; charset="utf-8" The comment above do_anonymous_page() dates back to 2005 and describes the pre-per-VMA-lock world where mmap_lock was always held on entry. Since CONFIG_PER_VMA_LOCK was introduced (6.4), the fault handler now has a fast path that enters holding only a per-VMA read lock, with mmap_lock not held at all. Update the comment to describe both entry contexts accurately. Signed-off-by: Aditya Sharma --- mm/memory.c | 22 +++++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) diff --git a/mm/memory.c b/mm/memory.c index c65e82c86..cc8dbbaea 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -5210,9 +5210,25 @@ static struct folio *alloc_anon_folio(struct vm_faul= t *vmf) } =20 /* - * We enter with non-exclusive mmap_lock (to exclude vma changes, - * but allow concurrent faults), and pte mapped but not yet locked. - * We return with mmap_lock still held, but pte unmapped and unlocked. + * We enter in one of two locking contexts: + * + * 1) VMA lock path (FAULT_FLAG_VMA_LOCK set): + * Entered holding a read lock on the faulting VMA (vma_start_read), + * but NOT holding mmap_lock. This is the fast path introduced with + * per-VMA locking (CONFIG_PER_VMA_LOCK). If this function cannot + * complete the fault (e.g. needs to wait on I/O or encounters a + * condition requiring the mm lock), it must return VM_FAULT_RETRY + * and the caller will fall back to the mmap_lock path below. + * + * 2) mmap_lock path (FAULT_FLAG_VMA_LOCK not set): + * Entered holding a non-exclusive (read) lock on mmap_lock, which + * excludes VMA tree modifications but allows concurrent faults on + * other VMAs. No per-VMA lock is held. + * + * In both cases, on entry the pte is mapped but not yet locked. + * On return, the pte is unmapped and unlocked, and whichever of + * the above locks was held on entry is still held (mmap_lock is + * not dropped, VMA read lock is not dropped, rather, the caller releases = it). */ static vm_fault_t do_anonymous_page(struct vm_fault *vmf) { --=20 2.34.1