[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260128121200.283932-1-clm@meta.com>
Date: Wed, 28 Jan 2026 04:08:36 -0800
From: Chris Mason <clm@...a.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
CC: Andrew Morton <akpm@...ux-foundation.org>,
Jarkko Sakkinen
<jarkko@...nel.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Thomas
Gleixner <tglx@...nel.org>, Ingo Molnar <mingo@...hat.com>,
Borislav Petkov
<bp@...en8.de>, <x86@...nel.org>,
"H . Peter Anvin" <hpa@...or.com>, Arnd
Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Dan Williams <dan.j.williams@...el.com>,
Vishal Verma
<vishal.l.verma@...el.com>,
Dave Jiang <dave.jiang@...el.com>,
Maarten
Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard
<mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>,
David Airlie
<airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
Jani Nikula
<jani.nikula@...ux.intel.com>,
Joonas Lahtinen
<joonas.lahtinen@...ux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@...el.com>,
Tvrtko Ursulin <tursulin@...ulin.net>,
Christian Koenig
<christian.koenig@....com>,
Huang Rui <ray.huang@....com>, Matthew Auld
<matthew.auld@...el.com>,
Matthew Brost <matthew.brost@...el.com>,
Alexander
Viro <viro@...iv.linux.org.uk>,
Christian Brauner <brauner@...nel.org>, Jan
Kara <jack@...e.cz>,
Benjamin LaHaise <bcrl@...ck.org>, Gao Xiang
<xiang@...nel.org>,
Chao Yu <chao@...nel.org>, Yue Hu <zbestahu@...il.com>,
Jeffle Xu <jefflexu@...ux.alibaba.com>,
Sandeep Dhavale <dhavale@...gle.com>,
Hongbo Li <lihongbo22@...wei.com>, Chunhai Guo <guochunhai@...o.com>,
Theodore Ts'o <tytso@....edu>,
Andreas Dilger <adilger.kernel@...ger.ca>,
Muchun Song <muchun.song@...ux.dev>,
Oscar Salvador <osalvador@...e.de>,
David Hildenbrand <david@...nel.org>,
Konstantin Komarov
<almaz.alexandrovich@...agon-software.com>,
Mike Marshall
<hubcap@...ibond.com>,
Martin Brandenburg <martin@...ibond.com>,
Tony Luck
<tony.luck@...el.com>,
Reinette Chatre <reinette.chatre@...el.com>,
Dave
Martin <Dave.Martin@....com>, James Morse <james.morse@....com>,
Babu Moger
<babu.moger@....com>, Carlos Maiolino <cem@...nel.org>,
Damien Le Moal
<dlemoal@...nel.org>,
Naohiro Aota <naohiro.aota@....com>,
Johannes Thumshirn
<jth@...nel.org>,
Matthew Wilcox <willy@...radead.org>,
"Liam R . Howlett"
<Liam.Howlett@...cle.com>,
Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport
<rppt@...nel.org>,
Suren Baghdasaryan <surenb@...gle.com>,
Michal Hocko
<mhocko@...e.com>, Hugh Dickins <hughd@...gle.com>,
Baolin Wang
<baolin.wang@...ux.alibaba.com>, Zi Yan <ziy@...dia.com>,
Nico Pache
<npache@...hat.com>, Ryan Roberts <ryan.roberts@....com>,
Dev Jain
<dev.jain@....com>, Barry Song <baohua@...nel.org>,
Lance Yang
<lance.yang@...ux.dev>, Jann Horn <jannh@...gle.com>,
Pedro Falcato
<pfalcato@...e.de>, David Howells <dhowells@...hat.com>,
Paul Moore
<paul@...l-moore.com>, James Morris <jmorris@...ei.org>,
"Serge E . Hallyn"
<serge@...lyn.com>,
Yury Norov <yury.norov@...il.com>,
Rasmus Villemoes
<linux@...musvillemoes.dk>,
<linux-sgx@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<nvdimm@...ts.linux.dev>, <linux-cxl@...r.kernel.org>,
<dri-devel@...ts.freedesktop.org>, <intel-gfx@...ts.freedesktop.org>,
<linux-fsdevel@...r.kernel.org>, <linux-aio@...ck.org>,
<linux-erofs@...ts.ozlabs.org>, <linux-ext4@...r.kernel.org>,
<linux-mm@...ck.org>, <ntfs3@...ts.linux.dev>,
<devel@...ts.orangefs.org>, <linux-xfs@...r.kernel.org>,
<keyrings@...r.kernel.org>, <linux-security-module@...r.kernel.org>,
Jason
Gunthorpe <jgg@...dia.com>
Subject: Re: [PATCH v2 07/13] mm: update secretmem to use VMA flags on mmap_prepare
Lorenzo Stoakes <lorenzo.stoakes@...cle.com> wrote:
> This patch updates secretmem to use the new vma_flags_t type which will
> soon supersede vm_flags_t altogether.
>
> In order to make this change we also have to update mlock_future_ok(), we
> replace the vm_flags_t parameter with a simple boolean is_vma_locked one,
> which also simplifies the invocation here.
>
> This is laying the groundwork for eliminating the vm_flags_t in
> vm_area_desc and more broadly throughout the kernel.
>
Hi everyone,
Running mm-new through AI review flagged this one:
> diff --git a/mm/mmap.c b/mm/mmap.c
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -225,12 +225,12 @@ static inline unsigned long round_hint_to_min(unsigned long hint)
> return hint;
> }
>
> -bool mlock_future_ok(const struct mm_struct *mm, vm_flags_t vm_flags,
> - unsigned long bytes)
> +bool mlock_future_ok(const struct mm_struct *mm, bool is_vma_locked,
> + unsigned long bytes)
> {
> unsigned long locked_pages, limit_pages;
>
> - if (!(vm_flags & VM_LOCKED) || capable(CAP_IPC_LOCK))
> + if (!is_vma_locked || capable(CAP_IPC_LOCK))
> return true;
[ ... ]
> @@ -416,7 +416,7 @@
> if (!can_do_mlock())
> return -EPERM;
>
> - if (!mlock_future_ok(mm, vm_flags, len))
> + if (!mlock_future_ok(mm, vm_flags & VM_LOCKED, len))
> return -EAGAIN;
This looks correct - do_mmap() now extracts the VM_LOCKED bit from
vm_flags and passes that to mlock_future_ok().
However, it appears check_brk_limits() was not updated when
mlock_future_ok() changed its signature. The function at mm/mmap.c:111
still passes the raw def_flags value:
return mlock_future_ok(current->mm, current->mm->def_flags, len)
? 0 : -EAGAIN;
When def_flags has any bit set, this converts to true, incorrectly
triggering mlock limit checks even when VM_LOCKED is not set. Should
this be passing (current->mm->def_flags & VM_LOCKED) instead?
[ ... ]
Additionally, the test stub at tools/testing/vma/vma_internal.h:1627
still has the old signature (mm, vm_flags_t vm_flags, bytes) while the
production code now uses (mm, bool is_vma_locked, bytes). This could
cause compilation issues or mask bugs in the test suite.
Powered by blists - more mailing lists