All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Stoakes <ljs@kernel.org>
To: Lance Yang <lance.yang@linux.dev>
Cc: akpm@linux-foundation.org, tsbogend@alpha.franken.de,
	 maddy@linux.ibm.com, mpe@ellerman.id.au,
	maarten.lankhorst@linux.intel.com,  mripard@kernel.org,
	tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch,
	 l.stach@pengutronix.de, inki.dae@samsung.com,
	sw0312.kim@samsung.com,  kyungmin.park@samsung.com,
	krzk@kernel.org, peter.griffin@linaro.org,
	 jani.nikula@linux.intel.com, joonas.lahtinen@linux.intel.com,
	rodrigo.vivi@intel.com,  tursulin@ursulin.net,
	robin.clark@oss.qualcomm.com, lumag@kernel.org, lyude@redhat.com,
	 dakr@kernel.org, tomi.valkeinen@ideasonboard.com,
	hjc@rock-chips.com,  heiko@sntech.de, andy.yan@rock-chips.com,
	thierry.reding@kernel.org,  mperttunen@nvidia.com,
	jonathanh@nvidia.com, kraxel@redhat.com,
	 dmitry.osipenko@collabora.com, zack.rusin@broadcom.com,
	matthew.brost@intel.com,  thomas.hellstrom@linux.intel.com,
	oleksandr_andrushchenko@epam.com, deller@gmx.de, bcrl@kvack.org,
	 viro@zeniv.linux.org.uk, brauner@kernel.org,
	muchun.song@linux.dev, osalvador@suse.de,  david@kernel.org,
	ziy@nvidia.com, baolin.wang@linux.alibaba.com,
	 liam@infradead.org, npache@redhat.com, ryan.roberts@arm.com,
	dev.jain@arm.com,  baohua@kernel.org, hughd@google.com,
	vbabka@kernel.org, rppt@kernel.org,  surenb@google.com,
	mhocko@suse.com, jannh@google.com, pfalcato@suse.de,
	 kees@kernel.org, perex@perex.cz, tiwai@suse.com,
	linux-mips@vger.kernel.org,  linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, dri-devel@lists.freedesktop.org,
	 etnaviv@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org,
	 linux-samsung-soc@vger.kernel.org,
	intel-gfx@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
	 freedreno@lists.freedesktop.org, nouveau@lists.freedesktop.org,
	 linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
	virtualization@lists.linux.dev,  intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org, linux-fbdev@vger.kernel.org,
	 linux-aio@kvack.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org,  linux-sound@vger.kernel.org
Subject: Re: [PATCH 13/13] mm/mremap: convert mremap code to use vma_flags_t
Date: Thu, 2 Jul 2026 17:07:10 +0100	[thread overview]
Message-ID: <akaJx8Zt8kazlrjq@lucifer> (raw)
In-Reply-To: <20260702134947.25189-1-lance.yang@linux.dev>

On Thu, Jul 02, 2026 at 09:49:47PM +0800, Lance Yang wrote:
>
> On Mon, Jun 29, 2026 at 08:25:36PM +0100, Lorenzo Stoakes wrote:
> >Replace use of the legacy vm_flags_t flags with vma_flags_t values
> >throughout the mremap logic.
> >
> >Additionally update comments to reflect the changes to be consistent.
> >
> >No functional change intended.
> >
> >Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> >---
>
> The vm_flags_set() cases below spell out vma_start_write(), but the
> vm_flags_clear() cases don't?

Yep as I said elsewhere, implicitly taking the lock is terrible and me doing
this is completely on purpose to get rid of that :)

But I haven't been clear enough clearly, so I should put the argument as to why
that's ok in the commit message.

Will do so on respin.

>
> Thanks, Lance
>
> > mm/mremap.c | 38 ++++++++++++++++++++------------------
> > 1 file changed, 20 insertions(+), 18 deletions(-)
> >
> >diff --git a/mm/mremap.c b/mm/mremap.c
> >index 079a0ba0c4a7..0ea43302b7ed 100644
> >--- a/mm/mremap.c
> >+++ b/mm/mremap.c
> >@@ -68,7 +68,7 @@ struct vma_remap_struct {
> > 	bool populate_expand;		/* mlock()'d expanded, must populate. */
> > 	enum mremap_type remap_type;	/* expand, shrink, etc. */
> > 	bool mmap_locked;		/* Is mm currently write-locked? */
> >-	unsigned long charged;		/* If VM_ACCOUNT, # pages to account. */
> >+	unsigned long charged;		/* If VMA_ACCOUNT_BIT, # pgs to account */
> > 	bool vmi_needs_invalidate;	/* Is the VMA iterator invalidated? */
> > };
> >
> >@@ -954,7 +954,7 @@ static unsigned long vrm_set_new_addr(struct vma_remap_struct *vrm)
> >
> > 	if (vrm->flags & MREMAP_FIXED)
> > 		map_flags |= MAP_FIXED;
> >-	if (vma->vm_flags & VM_MAYSHARE)
> >+	if (vma_test(vma, VMA_MAYSHARE_BIT))
> > 		map_flags |= MAP_SHARED;
> >
> > 	res = get_unmapped_area(vma->vm_file, new_addr, vrm->new_len, pgoff,
> >@@ -976,7 +976,7 @@ static bool vrm_calc_charge(struct vma_remap_struct *vrm)
> > {
> > 	unsigned long charged;
> >
> >-	if (!(vrm->vma->vm_flags & VM_ACCOUNT))
> >+	if (!vma_test(vrm->vma, VMA_ACCOUNT_BIT))
> > 		return true;
> >
> > 	/*
> >@@ -1003,7 +1003,7 @@ static bool vrm_calc_charge(struct vma_remap_struct *vrm)
> >  */
> > static void vrm_uncharge(struct vma_remap_struct *vrm)
> > {
> >-	if (!(vrm->vma->vm_flags & VM_ACCOUNT))
> >+	if (!vma_test(vrm->vma, VMA_ACCOUNT_BIT))
> > 		return;
> >
> > 	vm_unacct_memory(vrm->charged);
> >@@ -1023,7 +1023,7 @@ static void vrm_stat_account(struct vma_remap_struct *vrm,
> > 	struct vm_area_struct *vma = vrm->vma;
> >
> > 	vm_stat_account(mm, vma->vm_flags, pages);
> >-	if (vma->vm_flags & VM_LOCKED)
> >+	if (vma_test(vma, VMA_LOCKED_BIT))
> > 		mm->locked_vm += pages;
> > }
> >
> >@@ -1167,7 +1167,7 @@ static void unmap_source_vma(struct vma_remap_struct *vrm)
> > 	 * arose, in which case we _do_ wish to unmap the _new_ VMA, which means
> > 	 * we actually _do_ want it be unaccounted.
> > 	 */
> >-	bool accountable_move = (vma->vm_flags & VM_ACCOUNT) &&
> >+	bool accountable_move = vma_test(vma, VMA_ACCOUNT_BIT) &&
> > 		!(vrm->flags & MREMAP_DONTUNMAP);
> >
> > 	/*
> >@@ -1186,7 +1186,7 @@ static void unmap_source_vma(struct vma_remap_struct *vrm)
> > 	 * portions of the original VMA that remain.
> > 	 */
> > 	if (accountable_move) {
> >-		vm_flags_clear(vma, VM_ACCOUNT);
> >+		vma_clear_flags(vma, VMA_ACCOUNT_BIT);

This is called from move_vma() which holds the VMA write lock on vma.

> > 		/* We are about to split vma, so store the start/end. */
> > 		vm_start = vma->vm_start;
> > 		vm_end = vma->vm_end;
> >@@ -1211,8 +1211,8 @@ static void unmap_source_vma(struct vma_remap_struct *vrm)
> > 	 * |             |
> > 	 * |-------------|
> > 	 *
> >-	 * Having cleared VM_ACCOUNT from the whole VMA, after we unmap above
> >-	 * we'll end up with:
> >+	 * Having cleared VMA_ACCOUNT_BIT from the whole VMA, after we unmap
> >+	 * above we'll end up with:
> > 	 *
> > 	 *    addr  end
> > 	 *     |     |
> >@@ -1232,13 +1232,15 @@ static void unmap_source_vma(struct vma_remap_struct *vrm)
> > 		if (vm_start < addr) {
> > 			struct vm_area_struct *prev = vma_prev(&vmi);
> >
> >-			vm_flags_set(prev, VM_ACCOUNT); /* Acquires VMA lock. */
> >+			vma_start_write(prev);
> >+			vma_set_flags(prev, VMA_ACCOUNT_BIT);
> > 		}
> >
> > 		if (vm_end > end) {
> > 			struct vm_area_struct *next = vma_next(&vmi);
> >
> >-			vm_flags_set(next, VM_ACCOUNT); /* Acquires VMA lock. */
> >+			vma_start_write(next);
> >+			vma_set_flags(next, VMA_ACCOUNT_BIT);

These need vma_start_write() as referencing other, unlocked VMAs.

> > 		}
> > 	}
> > }
> >@@ -1321,8 +1323,8 @@ static void dontunmap_complete(struct vma_remap_struct *vrm,
> > 	unsigned long old_start = vrm->vma->vm_start;
> > 	unsigned long old_end = vrm->vma->vm_end;
> >
> >-	/* We always clear VM_LOCKED[ONFAULT] on the old VMA. */
> >-	vm_flags_clear(vrm->vma, VM_LOCKED_MASK);
> >+	/* We always clear VMA_LOCKED[ONFAULT]_BIT on the old VMA. */
> >+	vma_clear_flags_mask(vrm->vma, VMA_LOCKED_MASK);
-
Same as above, called from move_vma() with VMA write lock held.

> >
> > 	/*
> > 	 * anon_vma links of the old vma is no longer needed after its page
> >@@ -1758,14 +1760,14 @@ static int check_prep_vma(struct vma_remap_struct *vrm)
> > 	 * based on the original.  There are no known use cases for this
> > 	 * behavior.  As a result, fail such attempts.
> > 	 */
> >-	if (!old_len && !(vma->vm_flags & (VM_SHARED | VM_MAYSHARE))) {
> >+	if (!old_len && !vma_test_any(vma, VMA_SHARED_BIT, VMA_MAYSHARE_BIT)) {
> > 		pr_warn_once("%s (%d): attempted to duplicate a private mapping with mremap.  This is not supported.\n",
> > 			     current->comm, current->pid);
> > 		return -EINVAL;
> > 	}
> >
> > 	if ((vrm->flags & MREMAP_DONTUNMAP) &&
> >-			(vma->vm_flags & (VM_DONTEXPAND | VM_PFNMAP)))
> >+	    vma_test_any(vma, VMA_DONTEXPAND_BIT, VMA_PFNMAP_BIT))
> > 		return -EINVAL;
> >
> > 	/*
> >@@ -1795,7 +1797,7 @@ static int check_prep_vma(struct vma_remap_struct *vrm)
> > 		return 0;
> >
> > 	/* We are expanding and the VMA is mlock()'d so we need to populate. */
> >-	if (vma->vm_flags & VM_LOCKED)
> >+	if (vma_test(vma, VMA_LOCKED_BIT))
> > 		vrm->populate_expand = true;
> >
> > 	/* Need to be careful about a growing mapping */
> >@@ -1803,10 +1805,10 @@ static int check_prep_vma(struct vma_remap_struct *vrm)
> > 	if (pgoff + (new_len >> PAGE_SHIFT) < pgoff)
> > 		return -EINVAL;
> >
> >-	if (vma->vm_flags & (VM_DONTEXPAND | VM_PFNMAP))
> >+	if (vma_test_any(vma, VMA_DONTEXPAND_BIT, VMA_PFNMAP_BIT))
> > 		return -EFAULT;
> >
> >-	if (!mlock_future_ok(mm, vma->vm_flags & VM_LOCKED, vrm->delta))
> >+	if (!mlock_future_ok(mm, vma_test(vma, VMA_LOCKED_BIT), vrm->delta))
> > 		return -EAGAIN;
> >
> > 	if (!may_expand_vm(mm, &vma->flags, vrm->delta >> PAGE_SHIFT))
> >--
> >2.54.0
> >
> >

Cheers, Lorenzo


WARNING: multiple messages have this Message-ID (diff)
From: Lorenzo Stoakes <ljs@kernel.org>
To: Lance Yang <lance.yang@linux.dev>
Cc: akpm@linux-foundation.org, tsbogend@alpha.franken.de,
	maddy@linux.ibm.com, mpe@ellerman.id.au,
	maarten.lankhorst@linux.intel.com, mripard@kernel.org,
	simona@ffwll.ch, l.stach@pengutronix.de, inki.dae@samsung.com,
	sw0312.kim@samsung.com, kyungmin.park@samsung.com,
	krzk@kernel.org, peter.griffin@linaro.org,
	jani.nikula@linux.intel.com, joonas.lahtinen@linux.intel.com,
	rodrigo.vivi@intel.com, tursulin@ursulin.net,
	robin.clark@oss.qualcomm.com, lumag@kernel.org, dakr@kernel.org,
	tomi.valkeinen@ideasonboard.com, hjc@rock-chips.com,
	heiko@sntech.de, andy.yan@rock-chips.com,
	thierry.reding@kernel.org, mperttunen@nvidia.com,
	kraxel@redhat.com, dmitry.osipenko@collabora.com,
	zack.rusin@broadcom.com, matthew.brost@intel.com,
	thomas.hellstrom@linux.intel.com,
	oleksandr_andrushchenko@epam.com, deller@gmx.de, bcrl@kvack.org,
	viro@zeniv.linux.org.uk, brauner@kernel.org,
	muchun.song@linux.dev, osalvador@suse.de, david@kernel.org,
	ziy@nvidia.com, baolin.wang@linux.alibaba.com,
	liam@infradead.org, npache@redhat.com, ryan.roberts@arm.com,
	dev.jain@arm.com, baohua@kernel.org, hughd@google.com,
	vbabka@kernel.org, rppt@kernel.org, surenb@google.com,
	mhocko@suse.com, jannh@google.com, pfalcato@suse.de,
	kees@kernel.org, perex@perex.cz, tiwai@suse.com,
	linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, dri-devel@lists.freedesktop.org,
	etnaviv@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org,
	linux-samsung-soc@vger.kernel.org,
	intel-gfx@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
	freedreno@lists.freedesktop.org, nouveau@lists.freedesktop.org,
	linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
	virtualization@lists.linux.dev, intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org, linux-fbdev@vger.kernel.org,
	linux-aio@kvack.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, linux-sound@vger.kernel.org
Subject: Re: [PATCH 13/13] mm/mremap: convert mremap code to use vma_flags_t
Date: Thu, 2 Jul 2026 17:07:10 +0100	[thread overview]
Message-ID: <akaJx8Zt8kazlrjq@lucifer> (raw)
In-Reply-To: <20260702134947.25189-1-lance.yang@linux.dev>

On Thu, Jul 02, 2026 at 09:49:47PM +0800, Lance Yang wrote:
>
> On Mon, Jun 29, 2026 at 08:25:36PM +0100, Lorenzo Stoakes wrote:
> >Replace use of the legacy vm_flags_t flags with vma_flags_t values
> >throughout the mremap logic.
> >
> >Additionally update comments to reflect the changes to be consistent.
> >
> >No functional change intended.
> >
> >Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> >---
>
> The vm_flags_set() cases below spell out vma_start_write(), but the
> vm_flags_clear() cases don't?

Yep as I said elsewhere, implicitly taking the lock is terrible and me doing
this is completely on purpose to get rid of that :)

But I haven't been clear enough clearly, so I should put the argument as to why
that's ok in the commit message.

Will do so on respin.

>
> Thanks, Lance
>
> > mm/mremap.c | 38 ++++++++++++++++++++------------------
> > 1 file changed, 20 insertions(+), 18 deletions(-)
> >
> >diff --git a/mm/mremap.c b/mm/mremap.c
> >index 079a0ba0c4a7..0ea43302b7ed 100644
> >--- a/mm/mremap.c
> >+++ b/mm/mremap.c
> >@@ -68,7 +68,7 @@ struct vma_remap_struct {
> > 	bool populate_expand;		/* mlock()'d expanded, must populate. */
> > 	enum mremap_type remap_type;	/* expand, shrink, etc. */
> > 	bool mmap_locked;		/* Is mm currently write-locked? */
> >-	unsigned long charged;		/* If VM_ACCOUNT, # pages to account. */
> >+	unsigned long charged;		/* If VMA_ACCOUNT_BIT, # pgs to account */
> > 	bool vmi_needs_invalidate;	/* Is the VMA iterator invalidated? */
> > };
> >
> >@@ -954,7 +954,7 @@ static unsigned long vrm_set_new_addr(struct vma_remap_struct *vrm)
> >
> > 	if (vrm->flags & MREMAP_FIXED)
> > 		map_flags |= MAP_FIXED;
> >-	if (vma->vm_flags & VM_MAYSHARE)
> >+	if (vma_test(vma, VMA_MAYSHARE_BIT))
> > 		map_flags |= MAP_SHARED;
> >
> > 	res = get_unmapped_area(vma->vm_file, new_addr, vrm->new_len, pgoff,
> >@@ -976,7 +976,7 @@ static bool vrm_calc_charge(struct vma_remap_struct *vrm)
> > {
> > 	unsigned long charged;
> >
> >-	if (!(vrm->vma->vm_flags & VM_ACCOUNT))
> >+	if (!vma_test(vrm->vma, VMA_ACCOUNT_BIT))
> > 		return true;
> >
> > 	/*
> >@@ -1003,7 +1003,7 @@ static bool vrm_calc_charge(struct vma_remap_struct *vrm)
> >  */
> > static void vrm_uncharge(struct vma_remap_struct *vrm)
> > {
> >-	if (!(vrm->vma->vm_flags & VM_ACCOUNT))
> >+	if (!vma_test(vrm->vma, VMA_ACCOUNT_BIT))
> > 		return;
> >
> > 	vm_unacct_memory(vrm->charged);
> >@@ -1023,7 +1023,7 @@ static void vrm_stat_account(struct vma_remap_struct *vrm,
> > 	struct vm_area_struct *vma = vrm->vma;
> >
> > 	vm_stat_account(mm, vma->vm_flags, pages);
> >-	if (vma->vm_flags & VM_LOCKED)
> >+	if (vma_test(vma, VMA_LOCKED_BIT))
> > 		mm->locked_vm += pages;
> > }
> >
> >@@ -1167,7 +1167,7 @@ static void unmap_source_vma(struct vma_remap_struct *vrm)
> > 	 * arose, in which case we _do_ wish to unmap the _new_ VMA, which means
> > 	 * we actually _do_ want it be unaccounted.
> > 	 */
> >-	bool accountable_move = (vma->vm_flags & VM_ACCOUNT) &&
> >+	bool accountable_move = vma_test(vma, VMA_ACCOUNT_BIT) &&
> > 		!(vrm->flags & MREMAP_DONTUNMAP);
> >
> > 	/*
> >@@ -1186,7 +1186,7 @@ static void unmap_source_vma(struct vma_remap_struct *vrm)
> > 	 * portions of the original VMA that remain.
> > 	 */
> > 	if (accountable_move) {
> >-		vm_flags_clear(vma, VM_ACCOUNT);
> >+		vma_clear_flags(vma, VMA_ACCOUNT_BIT);

This is called from move_vma() which holds the VMA write lock on vma.

> > 		/* We are about to split vma, so store the start/end. */
> > 		vm_start = vma->vm_start;
> > 		vm_end = vma->vm_end;
> >@@ -1211,8 +1211,8 @@ static void unmap_source_vma(struct vma_remap_struct *vrm)
> > 	 * |             |
> > 	 * |-------------|
> > 	 *
> >-	 * Having cleared VM_ACCOUNT from the whole VMA, after we unmap above
> >-	 * we'll end up with:
> >+	 * Having cleared VMA_ACCOUNT_BIT from the whole VMA, after we unmap
> >+	 * above we'll end up with:
> > 	 *
> > 	 *    addr  end
> > 	 *     |     |
> >@@ -1232,13 +1232,15 @@ static void unmap_source_vma(struct vma_remap_struct *vrm)
> > 		if (vm_start < addr) {
> > 			struct vm_area_struct *prev = vma_prev(&vmi);
> >
> >-			vm_flags_set(prev, VM_ACCOUNT); /* Acquires VMA lock. */
> >+			vma_start_write(prev);
> >+			vma_set_flags(prev, VMA_ACCOUNT_BIT);
> > 		}
> >
> > 		if (vm_end > end) {
> > 			struct vm_area_struct *next = vma_next(&vmi);
> >
> >-			vm_flags_set(next, VM_ACCOUNT); /* Acquires VMA lock. */
> >+			vma_start_write(next);
> >+			vma_set_flags(next, VMA_ACCOUNT_BIT);

These need vma_start_write() as referencing other, unlocked VMAs.

> > 		}
> > 	}
> > }
> >@@ -1321,8 +1323,8 @@ static void dontunmap_complete(struct vma_remap_struct *vrm,
> > 	unsigned long old_start = vrm->vma->vm_start;
> > 	unsigned long old_end = vrm->vma->vm_end;
> >
> >-	/* We always clear VM_LOCKED[ONFAULT] on the old VMA. */
> >-	vm_flags_clear(vrm->vma, VM_LOCKED_MASK);
> >+	/* We always clear VMA_LOCKED[ONFAULT]_BIT on the old VMA. */
> >+	vma_clear_flags_mask(vrm->vma, VMA_LOCKED_MASK);
-
Same as above, called from move_vma() with VMA write lock held.

> >
> > 	/*
> > 	 * anon_vma links of the old vma is no longer needed after its page
> >@@ -1758,14 +1760,14 @@ static int check_prep_vma(struct vma_remap_struct *vrm)
> > 	 * based on the original.  There are no known use cases for this
> > 	 * behavior.  As a result, fail such attempts.
> > 	 */
> >-	if (!old_len && !(vma->vm_flags & (VM_SHARED | VM_MAYSHARE))) {
> >+	if (!old_len && !vma_test_any(vma, VMA_SHARED_BIT, VMA_MAYSHARE_BIT)) {
> > 		pr_warn_once("%s (%d): attempted to duplicate a private mapping with mremap.  This is not supported.\n",
> > 			     current->comm, current->pid);
> > 		return -EINVAL;
> > 	}
> >
> > 	if ((vrm->flags & MREMAP_DONTUNMAP) &&
> >-			(vma->vm_flags & (VM_DONTEXPAND | VM_PFNMAP)))
> >+	    vma_test_any(vma, VMA_DONTEXPAND_BIT, VMA_PFNMAP_BIT))
> > 		return -EINVAL;
> >
> > 	/*
> >@@ -1795,7 +1797,7 @@ static int check_prep_vma(struct vma_remap_struct *vrm)
> > 		return 0;
> >
> > 	/* We are expanding and the VMA is mlock()'d so we need to populate. */
> >-	if (vma->vm_flags & VM_LOCKED)
> >+	if (vma_test(vma, VMA_LOCKED_BIT))
> > 		vrm->populate_expand = true;
> >
> > 	/* Need to be careful about a growing mapping */
> >@@ -1803,10 +1805,10 @@ static int check_prep_vma(struct vma_remap_struct *vrm)
> > 	if (pgoff + (new_len >> PAGE_SHIFT) < pgoff)
> > 		return -EINVAL;
> >
> >-	if (vma->vm_flags & (VM_DONTEXPAND | VM_PFNMAP))
> >+	if (vma_test_any(vma, VMA_DONTEXPAND_BIT, VMA_PFNMAP_BIT))
> > 		return -EFAULT;
> >
> >-	if (!mlock_future_ok(mm, vma->vm_flags & VM_LOCKED, vrm->delta))
> >+	if (!mlock_future_ok(mm, vma_test(vma, VMA_LOCKED_BIT), vrm->delta))
> > 		return -EAGAIN;
> >
> > 	if (!may_expand_vm(mm, &vma->flags, vrm->delta >> PAGE_SHIFT))
> >--
> >2.54.0
> >
> >

Cheers, Lorenzo

  reply	other threads:[~2026-07-02 16:07 UTC|newest]

Thread overview: 90+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-29 19:25 [PATCH 00/13] convert more vm_flags_t users to vma_flags_t Lorenzo Stoakes
2026-06-29 19:25 ` Lorenzo Stoakes
2026-06-29 19:25 ` [PATCH 01/13] mm: introduce vma_flags_can_grow() and vma_can_grow() Lorenzo Stoakes
2026-06-29 19:25   ` Lorenzo Stoakes
2026-06-29 20:26   ` Zi Yan
2026-06-29 20:26     ` Zi Yan
2026-06-30  7:38     ` Lorenzo Stoakes
2026-06-30  7:38       ` Lorenzo Stoakes
2026-06-30 15:09       ` Zi Yan
2026-06-30 15:09         ` Zi Yan
2026-07-02  7:27   ` Lance Yang
2026-07-02  7:27     ` Lance Yang
2026-07-03 15:19   ` Zi Yan
2026-07-03 15:19     ` Zi Yan
2026-06-29 19:25 ` [PATCH 02/13] mm/vma: update do_mmap() to use vma_flags_t Lorenzo Stoakes
2026-06-29 19:25   ` Lorenzo Stoakes
2026-07-02 11:15   ` Lance Yang
2026-07-02 11:15     ` Lance Yang
2026-07-02 14:16     ` Lorenzo Stoakes
2026-07-02 14:16       ` Lorenzo Stoakes
2026-07-02 15:08       ` Lance Yang
2026-07-02 15:08         ` Lance Yang
2026-06-29 19:25 ` [PATCH 03/13] mm: convert __get_unmapped_area() " Lorenzo Stoakes
2026-06-29 19:25   ` Lorenzo Stoakes
2026-07-02 11:37   ` Lance Yang
2026-07-02 11:37     ` Lance Yang
2026-06-29 19:25 ` [PATCH 04/13] mm: update generic_get_unmapped_area[_topdown]() " Lorenzo Stoakes
2026-06-29 19:25   ` Lorenzo Stoakes
2026-07-02 11:41   ` Lance Yang
2026-07-02 11:41     ` Lance Yang
2026-06-29 19:25 ` [PATCH 05/13] mm: prefer mm->def_vma_flags in mm logic Lorenzo Stoakes
2026-06-29 19:25   ` Lorenzo Stoakes
2026-07-02 12:10   ` Lance Yang
2026-07-02 12:10     ` Lance Yang
2026-07-02 15:24     ` Lorenzo Stoakes
2026-07-02 15:24       ` Lorenzo Stoakes
2026-06-29 19:25 ` [PATCH 06/13] mm/vma: convert vm_pgprot_modify() to use vma_flags_t and rename Lorenzo Stoakes
2026-06-29 19:25   ` Lorenzo Stoakes
2026-07-02 12:21   ` Lance Yang
2026-07-02 12:21     ` Lance Yang
2026-07-02 15:29     ` Lorenzo Stoakes
2026-07-02 15:29       ` Lorenzo Stoakes
2026-06-29 19:25 ` [PATCH 07/13] mm/vma: rename vma_get_page_prot to vma_flags_to_page_prot Lorenzo Stoakes
2026-06-29 19:25   ` Lorenzo Stoakes
2026-07-02 12:25   ` Lance Yang
2026-07-02 12:25     ` Lance Yang
2026-06-29 19:25 ` [PATCH 08/13] mm: introduce vma_get_page_prot() and use it Lorenzo Stoakes
2026-06-29 19:25   ` Lorenzo Stoakes
2026-06-30  7:57   ` Thomas Zimmermann
2026-06-30  7:57     ` Thomas Zimmermann
2026-06-30 10:23   ` Jani Nikula
2026-06-30 10:23     ` Jani Nikula
2026-07-02 12:38   ` Lance Yang
2026-07-02 12:38     ` Lance Yang
2026-07-02 15:40     ` Lorenzo Stoakes
2026-07-02 15:40       ` Lorenzo Stoakes
2026-06-29 19:25 ` [PATCH 09/13] mm/vma: update create_init_stack_vma() to use vma_flags_t Lorenzo Stoakes
2026-06-29 19:25   ` Lorenzo Stoakes
2026-07-02 12:50   ` Lance Yang
2026-07-02 12:50     ` Lance Yang
2026-06-29 19:25 ` [PATCH 10/13] mm/vma: convert miscellaneous uses of VMA flags in core mm Lorenzo Stoakes
2026-06-29 19:25   ` Lorenzo Stoakes
2026-07-02 13:12   ` Lance Yang
2026-07-02 13:12     ` Lance Yang
2026-07-02 15:46     ` Lorenzo Stoakes
2026-07-02 15:46       ` Lorenzo Stoakes
2026-06-29 19:25 ` [PATCH 11/13] mm/mlock: convert mlock code to use vma_flags_t Lorenzo Stoakes
2026-06-29 19:25   ` Lorenzo Stoakes
2026-07-02 13:21   ` Lance Yang
2026-07-02 13:21     ` Lance Yang
2026-07-02 15:47     ` Lorenzo Stoakes
2026-07-02 15:47       ` Lorenzo Stoakes
2026-06-29 19:25 ` [PATCH 12/13] mm/mprotect: convert mprotect " Lorenzo Stoakes
2026-06-29 19:25   ` Lorenzo Stoakes
2026-07-01 16:09   ` Lance Yang
2026-07-01 16:09     ` Lance Yang
2026-07-02 15:53     ` Lorenzo Stoakes
2026-07-02 15:53       ` Lorenzo Stoakes
2026-06-29 19:25 ` [PATCH 13/13] mm/mremap: convert mremap " Lorenzo Stoakes
2026-06-29 19:25   ` Lorenzo Stoakes
2026-07-02 13:49   ` Lance Yang
2026-07-02 13:49     ` Lance Yang
2026-07-02 16:07     ` Lorenzo Stoakes [this message]
2026-07-02 16:07       ` Lorenzo Stoakes
2026-07-02 16:17       ` Lance Yang
2026-07-02 16:17         ` Lance Yang
2026-07-02 16:31         ` Lorenzo Stoakes
2026-07-02 16:31           ` Lorenzo Stoakes
2026-07-01 23:30 ` ✗ Fi.CI.BUILD: failure for convert more vm_flags_t users to vma_flags_t Patchwork
2026-07-02 16:08   ` Lorenzo Stoakes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=akaJx8Zt8kazlrjq@lucifer \
    --to=ljs@kernel.org \
    --cc=airlied@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=andy.yan@rock-chips.com \
    --cc=baohua@kernel.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=bcrl@kvack.org \
    --cc=brauner@kernel.org \
    --cc=dakr@kernel.org \
    --cc=david@kernel.org \
    --cc=deller@gmx.de \
    --cc=dev.jain@arm.com \
    --cc=dmitry.osipenko@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=etnaviv@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=heiko@sntech.de \
    --cc=hjc@rock-chips.com \
    --cc=hughd@google.com \
    --cc=inki.dae@samsung.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=jannh@google.com \
    --cc=jonathanh@nvidia.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=kees@kernel.org \
    --cc=kraxel@redhat.com \
    --cc=krzk@kernel.org \
    --cc=kyungmin.park@samsung.com \
    --cc=l.stach@pengutronix.de \
    --cc=lance.yang@linux.dev \
    --cc=liam@infradead.org \
    --cc=linux-aio@kvack.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lumag@kernel.org \
    --cc=lyude@redhat.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=maddy@linux.ibm.com \
    --cc=matthew.brost@intel.com \
    --cc=mhocko@suse.com \
    --cc=mpe@ellerman.id.au \
    --cc=mperttunen@nvidia.com \
    --cc=mripard@kernel.org \
    --cc=muchun.song@linux.dev \
    --cc=nouveau@lists.freedesktop.org \
    --cc=npache@redhat.com \
    --cc=oleksandr_andrushchenko@epam.com \
    --cc=osalvador@suse.de \
    --cc=perex@perex.cz \
    --cc=peter.griffin@linaro.org \
    --cc=pfalcato@suse.de \
    --cc=robin.clark@oss.qualcomm.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=rppt@kernel.org \
    --cc=ryan.roberts@arm.com \
    --cc=simona@ffwll.ch \
    --cc=surenb@google.com \
    --cc=sw0312.kim@samsung.com \
    --cc=thierry.reding@kernel.org \
    --cc=thomas.hellstrom@linux.intel.com \
    --cc=tiwai@suse.com \
    --cc=tomi.valkeinen@ideasonboard.com \
    --cc=tsbogend@alpha.franken.de \
    --cc=tursulin@ursulin.net \
    --cc=tzimmermann@suse.de \
    --cc=vbabka@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=virtualization@lists.linux.dev \
    --cc=xen-devel@lists.xenproject.org \
    --cc=zack.rusin@broadcom.com \
    --cc=ziy@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.