Re: [PATCH v3] mm/secretmem: properly account locked pages

["David Hildenbrand (Arm)" <david@kernel.org>]

On 8/26/26 18:30, Lorenzo Stoakes (ARM) wrote:
> secretmem accounts folios by treating memory as if it were mlock()'d and
> thus limited by the RLIMIT_MEMLOCK limit.
> 
> However the folios are unevictable and remain so until the inode is
> evicted, eliminating usual mlock() semantics - mapping folios then
> unmapping them does not clear their unevictable state, since it depends on
> AS_UNEVICTABLE, not PG_mlocked.
> 
> A user can therefore easily work around the RLIMIT_MEMLOCK limit - simply
> map then unmap and VmLck no longer counts the secretmem range. Worse,
> folios are not accounted in the process's RSS, meaning the OOM killer won't
> know to kill the process.
> 
> Repeatedly mapping/unmapping (or forking) can then result in the
> consumption of all available system memory with unevictable folios and
> cause system instability.
> 
> A secretmem fd can be passed between processes and over fork so a
> per-process limit simply does not make sense, so follow the precedent set
> by io_uring, perf, skbuff, iommufd and xdp by tracking the number of locked
> pages in user_struct->locked_vm.
> 
> Since the scope tracked is actually inode lifetime, the RLIMIT_MEMLOCK
> applies per-user not per-process, so it doesn't make sense to bypass for
> users with CAP_IPC_LOCK, therefore remove this bypass.
> 
> There is simply no reason to carry on marking the mapping as mlock()'d
> since it's misleading and the lifecycle is now correctly handled, so remove
> this too.
> 
> Note that secretmem does not support any form of truncation (including hole
> punching) and the folios are unreclaimable, so the folios need only be
> accounted on fault and unaccounted on inode destruction.
> 
> __secretmem_account_pages() is more or less a duplicate of the code that
> io_uring etc. use, but since this is a bug fix that needs backporting,
> defer any de-duplication efforts to a follow-up.
> 
> test_mlock_limit() asserts mlock_future_ok() on mmap(), however this has
> been removed, so remove the test altogether for the fix. A new test will be
> sent separately for upstream.
> 
> Reported-by: Daehyeon Ko <4ncienth@gmail.com>
> Closes: https://lore.kernel.org/linux-mm/20260813225328.2010303-1-4ncienth@gmail.com/
> Fixes: 1507f51255c9 ("mm: introduce memfd_secret system call to create "secret" memory areas")
> Cc: stable@vger.kernel.org
> Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> Acked-by: David Hildenbrand (Arm) <david@kernel.org>
> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> ---

LGTM thanks

-- 
Cheers,

David