From: Lance Yang <lance.yang@linux.dev>
To: ljs@kernel.org
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, lance.yang@linux.dev,
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 21:49:47 +0800 [thread overview]
Message-ID: <20260702134947.25189-1-lance.yang@linux.dev> (raw)
In-Reply-To: <380f761d35a3faa4370f8b3f92e3d4af3d4c7110.1782760670.git.ljs@kernel.org>
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?
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);
> /* 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);
> }
> }
> }
>@@ -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);
>
> /*
> * 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
>
>
WARNING: multiple messages have this Message-ID (diff)
From: Lance Yang <lance.yang@linux.dev>
To: ljs@kernel.org
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, lance.yang@linux.dev,
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 21:49:47 +0800 [thread overview]
Message-ID: <20260702134947.25189-1-lance.yang@linux.dev> (raw)
In-Reply-To: <380f761d35a3faa4370f8b3f92e3d4af3d4c7110.1782760670.git.ljs@kernel.org>
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?
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);
> /* 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);
> }
> }
> }
>@@ -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);
>
> /*
> * 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
>
>
next prev parent reply other threads:[~2026-07-02 13:50 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 [this message]
2026-07-02 13:49 ` Lance Yang
2026-07-02 16:07 ` Lorenzo Stoakes
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=20260702134947.25189-1-lance.yang@linux.dev \
--to=lance.yang@linux.dev \
--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=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=ljs@kernel.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.