Re: [PATCH 20/30] mm/vma: introduce vma_assert_can_modify()
Gregory Price <[email protected]> Fri, 10 Jul 2026 15:05:27 -0400
| Newsgroups | org.kernel.vger.linux-sgx,dev.linux.lists.damon,dev.linux.lists.iommu,dev.linux.lists.nvdimm,org.freedesktop.lists.dri-devel,org.kernel.vger.kvm,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-parisc,org.kernel.vger.linux-perf-users,org.kernel.vger.linux-tegra,org.kernel.vger.linux-trace-kernel,org.kvack.linux-mm |
|---|---|
| Message-ID | <alFCd1RtttwxKBLc@gourry-fedora-PF4VCD3F> |
On Mon, Jun 29, 2026 at 01:23:31PM +0100, Lorenzo Stoakes wrote: > 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). > curiosity: I presume this happens mostly during init and/or teardown of a vma? > 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 <[email protected]> Reviewed-by: Gregory Price <[email protected]>