Linux ARM-MSM sub-architecture
 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 02/13] mm/vma: update do_mmap() to use vma_flags_t
Date: Thu, 2 Jul 2026 15:16:20 +0100	[thread overview]
Message-ID: <akZwsS-_cywsXSjL@lucifer> (raw)
In-Reply-To: <20260702111531.64883-1-lance.yang@linux.dev>

On Thu, Jul 02, 2026 at 07:15:31PM +0800, Lance Yang wrote:
>
> On Mon, Jun 29, 2026 at 08:25:25PM +0100, Lorenzo Stoakes wrote:
> >The core do_mmap() function accepts a vm_flags_t parameter which it then
> >manipulates before passing to mmap_region() to do the heavy lifting of the
> >memory mapping.
> >
> >Update do_mmap() to instead accept a vma_flags_t parameter, and adjust all
> >the logic within do_mmap() to manipulate this instead.
> >
> >This is as part of the ongoing effort to convert VMA flags from a system
> >word size to a bitmap type which allows us to unrestrict the number of VMA
> >flags, as well as gain control over how VMA flag manipulation occurs.
> >
> >We do not cascade these changes to all functions which accept vm_flags_t,
> >but rather use vma_flags_to_legacy() where necessary, specifically
> >deferring converting calc_vm_prot_bits(), calc_vm_flag_bits() and
> >__get_unmapped_area() to vma_flags_t.
> >
> >Also utilise the new vma_flags_can_grow() predicate which correctly handles
> >the case of architectures without upward growing stacks.
> >
> >As part of this change, introduce VMA_SHADOW_STACK so we can correctly
> >handle the case of the shadow stack not being defined.
> >
> >No functional change intended.
> >
> >Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> >---
>
> Not exactly a small one :) I stared at this patch for a while, hopefully
> don't miss anythig ...

Yeah sorry maybe I could have broken this down more!

>
> Just one tiny nit below. Overall, LGTM, feel free to add:
>
> Reviewed-by: Lance Yang <lance.yang@linux.dev>

Thanks!

>
> [...]
> >diff --git a/mm/mmap.c b/mm/mmap.c
> >index 46174e706bbe..547352183214 100644
> >--- a/mm/mmap.c
> >+++ b/mm/mmap.c
> [...]
> >@@ -488,23 +496,27 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
> > 		 * Check to see if we are violating any seals and update VMA
> > 		 * flags if necessary to avoid future seal violations.
> > 		 */
> >-		err = memfd_check_seals_mmap(file, &vm_flags);
> >+		err = memfd_check_seals_mmap(file, &vma_flags);
> > 		if (err)
> > 			return (unsigned long)err;
> > 	} else {
> > 		switch (flags & MAP_TYPE) {
> > 		case MAP_SHARED:
> >-			if (vm_flags & (VM_GROWSDOWN|VM_GROWSUP))
> >+			if (vma_flags_can_grow(&vma_flags))
> > 				return -EINVAL;
> > 			/*
> > 			 * Ignore pgoff.
> > 			 */
> > 			pgoff = 0;
> >-			vm_flags |= VM_SHARED | VM_MAYSHARE;
> >+			vma_flags_set(&vma_flags, VMA_SHARED_BIT, VMA_MAYSHARE_BIT);
> > 			break;
> >-		case MAP_DROPPABLE:
> >-			if (VM_DROPPABLE == VM_NONE)
> >+		case MAP_DROPPABLE: {
> >+			vma_flags_t droppable = VMA_DROPPABLE;
> >+
> >+			if (vma_flags_empty(&droppable))
> > 				return -EOPNOTSUPP;
> >+			vma_flags_set_mask(&vma_flags, droppable);
> >+
> > 			/*
> > 			 * A locked or stack area makes no sense to be droppable.
> > 			 *
> >@@ -515,23 +527,24 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
> > 			 */
> > 			if (flags & (MAP_LOCKED | MAP_HUGETLB))
> > 			        return -EINVAL;
> >-			if (vm_flags & (VM_GROWSDOWN | VM_GROWSUP))
> >+			if (vma_flags_can_grow(&vma_flags))
> > 			        return -EINVAL;
> >
> >-			vm_flags |= VM_DROPPABLE;
>
> Old code checked VM_GROWSDOWN|VM_GROWSUP before seting VM_DROPPABLE. New
> code flips that around. Hmm, shouldn't master, just made me look twice ;)
>
> Maybe keep old order?

I guess I feared that defining droppable above then referencing it below would
be less clear?

Can move if you feel strongly about it, and sorry for making the move at the
same time as the general vm_flags_t -> vma_flags_t refactor as it does make that
less clear...

>
> Cheers, Lance
>
> >-
> > 			/*
> > 			 * If the pages can be dropped, then it doesn't make
> > 			 * sense to reserve them.
> > 			 */
> >-			vm_flags |= VM_NORESERVE;
> >+			vma_flags_set(&vma_flags, VMA_NORESERVE_BIT);
> >
> > 			/*
> > 			 * Likewise, they're volatile enough that they
> > 			 * shouldn't survive forks or coredumps.
> > 			 */
> >-			vm_flags |= VM_WIPEONFORK | VM_DONTDUMP;
> >+			vma_flags_set(&vma_flags, VMA_WIPEONFORK_BIT,
> >+				      VMA_DONTDUMP_BIT);
> >+
> > 			fallthrough;
> >+		}
> > 		case MAP_PRIVATE:
> > 			/*
> > 			 * Set pgoff according to addr for anon_vma.
> [...]

Thanks, Lorenzo

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

Thread overview: 43+ 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 ` [PATCH 01/13] mm: introduce vma_flags_can_grow() and vma_can_grow() Lorenzo Stoakes
2026-06-29 20:26   ` Zi Yan
2026-06-30  7:38     ` Lorenzo Stoakes
2026-06-30 15:09       ` Zi Yan
2026-07-02  7:27   ` Lance Yang
2026-06-29 19:25 ` [PATCH 02/13] mm/vma: update do_mmap() to use vma_flags_t Lorenzo Stoakes
2026-07-02 11:15   ` Lance Yang
2026-07-02 14:16     ` Lorenzo Stoakes [this message]
2026-07-02 15:08       ` Lance Yang
2026-06-29 19:25 ` [PATCH 03/13] mm: convert __get_unmapped_area() " Lorenzo Stoakes
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-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-07-02 12:10   ` Lance Yang
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-07-02 12:21   ` Lance Yang
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-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-30  7:57   ` Thomas Zimmermann
2026-06-30 10:23   ` Jani Nikula
2026-07-02 12:38   ` Lance Yang
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-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-07-02 13:12   ` Lance Yang
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-07-02 13:21   ` Lance Yang
2026-07-02 15:47     ` Lorenzo Stoakes
2026-06-29 19:25 ` [PATCH 12/13] mm/mprotect: convert mprotect " Lorenzo Stoakes
2026-07-01 16:09   ` Lance Yang
2026-07-02 15:53     ` Lorenzo Stoakes
2026-06-29 19:25 ` [PATCH 13/13] mm/mremap: convert mremap " Lorenzo Stoakes
2026-07-02 13:49   ` Lance Yang
2026-07-02 16:07     ` Lorenzo Stoakes
2026-07-02 16:17       ` Lance Yang
2026-07-02 16:31         ` 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=akZwsS-_cywsXSjL@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox