From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from r3-18.sinamail.sina.com.cn (r3-18.sinamail.sina.com.cn [202.108.3.18]) (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 A53FA3EBF3B for ; Fri, 23 Jan 2026 23:36:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.108.3.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769211371; cv=none; b=rhXjFm6XJon7Pl5mm9dAGEW+o62ZioVeULUtAtd2/qU/r86b0tBgvOlVO+uxecg55IQdssZfyFuibkR7OamJphu2jOJZnFDV7HqGIrfKu3TQ+siKBhF5dJWEcsbivs7OF3fHLdpUqYIr6O4T9/7coMyAlwX6HOv0gvMRFV4KHpE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769211371; c=relaxed/simple; bh=tULjJ8Vvrv++Zb7mVhrcdBNWAVEcqaPhZh3PzSTrH0U=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QuLdomQsTjyEHTqIJR4PrnT85yzxsGKHNmlT7rQE5TOC0BYBzuRCqUnnI1Klz3pmV2av7bu1obxDifOWKdgPBaAefPefV3jOMqp+LmNC9+YYfOMd97pAzy5m9Nyf1d8oJQhTr55hxy+GxaqlcfR9BuCoEGDbjuKio/NkAiQfRTg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sina.com; spf=pass smtp.mailfrom=sina.com; dkim=pass (1024-bit key) header.d=sina.com header.i=@sina.com header.b=zpwN9HX5; arc=none smtp.client-ip=202.108.3.18 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sina.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sina.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=sina.com header.i=@sina.com header.b="zpwN9HX5" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sina.com; s=201208; t=1769211367; bh=qeRxzUMP9svcMWdDmykegfRAU5lDXzkoq901kD2a6LI=; h=From:Subject:Date:Message-ID; b=zpwN9HX5fdP0Awlab42Oq0CEAGn3qEb1vz6NQf3wVdZ/ppKqY8C07qT75WEGRsonq 11KEsKS0LTvmrR3VZlsASU2SWv6KzrBkH8DpybFV6Ouz5uPR9XAnJZL4ES+VxCfJLr QSYmmY6jEj0//HMTq9LQZz68q9wOXsvVs+tzM8Q8= X-SMAIL-HELO: localhost.localdomain Received: from unknown (HELO localhost.localdomain)([114.249.58.160]) by sina.com (10.54.253.32) with ESMTP id 697405E00000164D; Fri, 24 Jan 2026 07:36:03 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com Authentication-Results: sina.com; spf=none smtp.mailfrom=hdanton@sina.com; dkim=none header.i=none; dmarc=none action=none header.from=hdanton@sina.com X-SMAIL-MID: 4303764456699 X-SMAIL-UIID: 3327A5830D0942A58BDDC99F01B85E9B-20260124-073603-1 From: Hillf Danton To: Lorenzo Stoakes Cc: Andrew Morton , Suren Baghdasaryan , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Boqun Feng , Waiman Long , Sebastian Andrzej Siewior Subject: Re: [PATCH RESEND v3 10/10] mm/vma: add and use vma_assert_stabilised() Date: Sat, 24 Jan 2026 07:35:48 +0800 Message-ID: <20260123233550.2378-1-hdanton@sina.com> In-Reply-To: <43c90424ba0874a71bb7ab9d6423b3a2bf616f8e.1769086312.git.lorenzo.stoakes@oracle.com> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Thu, 22 Jan 2026 13:02:02 +0000 Lorenzo Stoakes wrote: > +/** > + * vma_assert_stabilised() - assert that this VMA cannot be changed from > + * underneath us either by having a VMA or mmap lock held. > + * @vma: The VMA whose stability we wish to assess. > + * > + * If lockdep is enabled we can precisely ensure stability via either an mmap > + * lock owned by us or a specific VMA lock. > + * > + * With lockdep disabled we may sometimes race with other threads acquiring the > + * mmap read lock simultaneous with our VMA read lock. > + */ > +static inline void vma_assert_stabilised(struct vm_area_struct *vma) > +{ > + /* > + * If another thread owns an mmap lock, it may go away at any time, and > + * thus is no guarantee of stability. > + * > + * If lockdep is enabled we can accurately determine if an mmap lock is > + * held and owned by us. Otherwise we must approximate. > + * > + * It doesn't necessarily mean we are not stabilised however, as we may > + * hold a VMA read lock (not a write lock as this would require an owned > + * mmap lock). > + * > + * If (assuming lockdep is not enabled) we were to assert a VMA read > + * lock first we may also run into issues, as other threads can hold VMA > + * read locks simlutaneous to us. > + * > + * Therefore if lockdep is not enabled we risk a false negative (i.e. no > + * assert fired). If accurate checking is required, enable lockdep. > + */ > + if (IS_ENABLED(CONFIG_LOCKDEP)) { > + if (lockdep_is_held(&vma->vm_mm->mmap_lock)) > + return; > + } else { > + if (rwsem_is_locked(&vma->vm_mm->mmap_lock)) > + return; > + } In case of the mmap_lock, rwsem_is_locked has nothing to do with lockdep_is_held, as the latter is noop without lockdep enabled. And the former fails to match the us in "assert that this VMA cannot be changed from underneath us either by having a VMA or mmap lock held". That said, you are adding confusion. > + > + /* > + * We're not stabilised by the mmap lock, so assert that we're > + * stabilised by a VMA lock. > + */ > + vma_assert_locked(vma); > +} > +