From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6353AC44507 for ; Thu, 9 Jul 2026 08:54:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=fMElnkAA3dH9tkV3ujJDVRVotqOCyLiAo2v1/Xngwtc=; b=ahmUphjJlds5US nlWtdQkI42DFPfL0QJ2EgY/PVgqzxDA664F5TrH9y9RF0LUWTW96HUpN9bVzLOQ3MfXF8f9ZvVjRu hdgwXLhfZKm1nlEpK6w66e174PQUKKYOdMgN3I9YkVr1CVPGWz9bRRBgjzd9VFqK/X/vHCaQ5Nwgc 2ned1bVkpwryK0d4PnhmNkkiDU5++VJoOfTGT5we1XI518ZhNPa0x1kPkKN2+7j0ItCcBPBP6AUR2 GziQhNczu1pOJ2njxX9W2P//5Tu3402MZ80qM6LwDvWoa1VFAXkvfQlH1TJ2KbXH1Vc1BiNWuZ3zl pzixmn8ohAdtkmFjXX6w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1whkWP-00000001dU4-3yV7; Thu, 09 Jul 2026 08:54:17 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wh2ps-0000000EiUg-08BL; Tue, 07 Jul 2026 10:15:28 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 64240424AD; Tue, 7 Jul 2026 10:15:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DDAC81F00A3D; Tue, 7 Jul 2026 10:15:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783419327; bh=mNSla9Czr4vFeuTIzrP/cHDzh+yx/IrTUvaJ5OnP34U=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=HluYhwOWRqwjbw9mnNEjPVnyh7tR+UBSnSv/otgjpUQBigWOwZUJOYkpU0LnGQPOd 9JWuafQR68ncbIWqn0jW8jTfwPafpmeDnt2Wvr8VLfjDqTgkyFdLwQrzBX5aGYlPBy bdDr9uov5pNq61DLoYMBBHIrYLPaluS9cGGvVLuwrNNgpnc0PxTOy1Y4Jv6WgqJLPU g8L2HsabDqHedwwaZisYTmwsI8Liu2LIO7hoQNV8VhXPReqA934JiUn5O3mwQK8rxr zZFBy1M3lH7Q7XggDkvTulkUo1eG7DFZ7mTqdd75PKoMBF8VkjG7TCZVSFf+WpnFzU vO+QqUik5Cd9A== Date: Tue, 7 Jul 2026 11:15:02 +0100 From: Lorenzo Stoakes To: Zi Yan Cc: Andrew Morton , Thomas Bogendoerfer , Madhavan Srinivasan , Michael Ellerman , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Lucas Stach , Inki Dae , Seung-Woo Kim , Kyungmin Park , Krzysztof Kozlowski , Peter Griffin , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , Rob Clark , Dmitry Baryshkov , Lyude Paul , Danilo Krummrich , Tomi Valkeinen , Sandy Huang , Heiko =?utf-8?Q?St=C3=BCbner?= , Andy Yan , Thierry Reding , Mikko Perttunen , Jonathan Hunter , Gerd Hoffmann , Dmitry Osipenko , Zack Rusin , Matthew Brost , Thomas Hellstrom , Oleksandr Andrushchenko , Helge Deller , Benjamin LaHaise , Alexander Viro , Christian Brauner , Muchun Song , Oscar Salvador , David Hildenbrand , Baolin Wang , "Liam R . Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Hugh Dickins , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Jann Horn , Pedro Falcato , Kees Cook , Jaroslav Kysela , Takashi Iwai , 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 Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Mailman-Approved-At: Thu, 09 Jul 2026 01:48:24 -0700 X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org On Mon, Jul 06, 2026 at 10:10:32PM -0400, Zi Yan wrote: > On Mon Jun 29, 2026 at 3:25 PM EDT, 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 > > --- > > arch/mips/kernel/vdso.c | 4 +-- > > fs/aio.c | 2 +- > > include/linux/memfd.h | 6 ++-- > > include/linux/mm.h | 6 ++-- > > ipc/shm.c | 3 +- > > mm/memfd.c | 15 ++++----- > > mm/mmap.c | 67 ++++++++++++++++++++++++----------------- > > mm/nommu.c | 3 +- > > mm/util.c | 10 +++--- > > mm/vma.c | 7 ++--- > > mm/vma.h | 2 +- > > 11 files changed, 69 insertions(+), 56 deletions(-) > > > > > > > > > -static int check_write_seal(vm_flags_t *vm_flags_ptr) > > +static int check_write_seal(vma_flags_t *vma_flags_ptr) > > { > > - vm_flags_t vm_flags = *vm_flags_ptr; > > - vm_flags_t mask = vm_flags & (VM_SHARED | VM_WRITE); > > - > > /* If a private mapping then writability is irrelevant. */ > > - if (!(mask & VM_SHARED)) > > + if (!vma_flags_test(vma_flags_ptr, VMA_SHARED_BIT)) > > return 0; > > > > /* > > * New PROT_WRITE and MAP_SHARED mmaps are not allowed when > > * write seals are active. > > */ > > - if (mask & VM_WRITE) > > + if (vma_flags_test(vma_flags_ptr, VMA_WRITE_BIT)) > > return -EPERM; > > > > /* > > * This is a read-only mapping, disallow mprotect() from making a > > * write-sealed mapping writable in future. > > */ > > - *vm_flags_ptr &= ~VM_MAYWRITE; > > + vma_flags_clear(vma_flags_ptr, VMA_MAYWRITE_BIT); > > > > return 0; > > } > > This function alone changed its original behavior, since vm_flags is a > snapshot of *vm_flags_ptr, but after the change this snapshot is gone. > But its only caller memfd_check_seals_mmap() gets vm_flags_ptr from the > input parameter of do_mmap(), so the overall behavior does not change. Right yeah, the snapshot was always just a convenience thing :) > > > > > + 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; > > - > > Lance pointed out the reordering of setting VMA_DROPPABLE and checking > of can_grow, but these flags are not overlapped and there is no parallel > writer to vma_flags. So it is still no functional change, just not > mechanical changes. :) Right yes exactly :) > > Otherwise, LGTM. > > Reviewed-by: Zi Yan Thanks! > > -- > Best Regards, > Yan, Zi > Cheers, Lorenzo _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip