From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.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 B5E3340F8F4; Mon, 29 Jun 2026 12:24:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782735897; cv=none; b=oOZiulbsOuDo/7OAoFTaoO7eY1nD3YqssjPSKN544TCOePw3BdTJ1qSw+jRNouUvYu5FZxe21owFR7F63vH3OYNn+g1SDgDULpf6oGaUy34ynIr6shjINCSkkksWmnqjX4Wn9fW/p2uJnIDVlPVE1yoGeg4KZ19dVd+UoNzyM3A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782735897; c=relaxed/simple; bh=t4Dqg4wAhRmxu/SFpMe36wsTX3tq8kIQZ9qm/SU91eg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iiGL5Rf1KCzXUKFyRqTSdZi4Ey/ylJ9UbDK492wx3tPqcEhxcMWa0qkuOjud4OcpNEFhvIuhBUx/H5v+PBRLsshO8U/XeVV1oDb4DTcxooDfrdbr3taQOJkzdFbOyC8M7Xf4gl5EluLvdLJ/A27NpL2Tb81N43r8609eFfdOM4Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ImB78Xm5; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ImB78Xm5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 819851F000E9; Mon, 29 Jun 2026 12:24:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782735895; bh=q/zmrg1aZZtj5Tmn6K9F810cSj24cLspebCxVYr6+vM=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=ImB78Xm5cq6RrDbmQ3J6tzrC3HLEzs7wzd0LC9qXAFx7cd4y0IcRNHPEQjaCD2kCv t7/cUJE9y3I1sPoHMYrCyG34SjvURuw2nRDZurNb2jCyVmORwYVTl6EDHnREKFXwhb Mbf3AenyI1/h0SqiWNCY23Z13tJZjuXnBQ9SfIzuKiUPMbB3m3+TLCnoGKijqfR3NC 1tp2JiV+gIsscH67BC9LhRi/4QlmripqWzergkvG/ngTTNDMnQd/mgZN6SNyqqbauP IGwwhnbxNqzXNkjYdSC9Q47btcLisY0PN7QS+5n8ONjQMKE+Ptl6DATcGPdaGI14cl pHvsw1KC9+rOQ== From: Lorenzo Stoakes To: Andrew Morton Cc: Russell King , Dinh Nguyen , Simon Schuster , "James E . J . Bottomley" , Helge Deller , Jarkko Sakkinen , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, Ian Abbott , H Hartley Sweeten , Lucas Stach , David Airlie , Simona Vetter , Patrik Jakobsson , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Rob Clark , Dmitry Baryshkov , Tomi Valkeinen , Thierry Reding , Mikko Perttunen , Jonathan Hunter , Christian Koenig , Huang Rui , Ankit Agrawal , Alex Williamson , Alexander Viro , Christian Brauner , Dan Williams , Muchun Song , Oscar Salvador , David Hildenbrand , Suren Baghdasaryan , "Liam R . Howlett" , Matthew Wilcox , Marek Szyprowski , Peter Zijlstra , Arnaldo Carvalho de Melo , Namhyung Kim , Masami Hiramatsu , Oleg Nesterov , Steven Rostedt , SeongJae Park , Miaohe Lin , Hugh Dickins , Mike Rapoport , Kees Cook , Paolo Bonzini , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-parisc@vger.kernel.org, linux-sgx@vger.kernel.org, etnaviv@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org, linux-tegra@vger.kernel.org, kvm@vger.kernel.org, linux-fsdevel@vger.kernel.org, nvdimm@lists.linux.dev, linux-mm@kvack.org, iommu@lists.linux.dev, linux-perf-users@vger.kernel.org, linux-trace-kernel@vger.kernel.org, kasan-dev@googlegroups.com, damon@lists.linux.dev, Pedro Falcato , Rik van Riel , Harry Yoo , Jann Horn Subject: [PATCH 20/30] mm/vma: introduce vma_assert_can_modify() Date: Mon, 29 Jun 2026 13:23:31 +0100 Message-ID: <23c7602c58cacc23ef22618a27af9a2d54addf58.1782735110.git.ljs@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: 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 vma_assert_write_locked() and vma_assert_attached() are useful for their own purposes, however VMA code absolutely does allow the modification of non-write locked VMAs if they are at that point detached (i.e. unreachable from anywhere). It's therefore useful to be able to assert that a VMA is either detached (modification doesn't matter) or write locked (you're explicitly locked for modification). Therefore introduce vma_assert_can_modify() for this purpose. While we're here, make vma_is_attached() available generally - if !CONFIG_PER_VMA_LOCKS, then there's no sense in which a VMA is detached (vma_mark_detached() is a noop), so have this default to true in this case. Signed-off-by: Lorenzo Stoakes --- include/linux/mmap_lock.h | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/include/linux/mmap_lock.h b/include/linux/mmap_lock.h index 04b8f61ece5d..d513286d8160 100644 --- a/include/linux/mmap_lock.h +++ b/include/linux/mmap_lock.h @@ -506,6 +506,8 @@ static inline __must_check int vma_start_write_killable(struct vm_area_struct *vma) { return 0; } static inline void vma_assert_write_locked(struct vm_area_struct *vma) { mmap_assert_write_locked(vma->vm_mm); } +static inline bool vma_is_attached(struct vm_area_struct *vma) + { return true; } static inline void vma_assert_attached(struct vm_area_struct *vma) {} static inline void vma_assert_detached(struct vm_area_struct *vma) {} static inline void vma_mark_attached(struct vm_area_struct *vma) {} @@ -530,6 +532,12 @@ static inline void vma_assert_stabilised(struct vm_area_struct *vma) #endif /* CONFIG_PER_VMA_LOCK */ +static inline void vma_assert_can_modify(struct vm_area_struct *vma) +{ + if (vma_is_attached(vma)) + vma_assert_write_locked(vma); +} + static inline void mmap_write_lock(struct mm_struct *mm) { __mmap_lock_trace_start_locking(mm, true); -- 2.54.0