From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 040D03E7159; Wed, 14 Oct 2026 21:51:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792014703; cv=none; b=hnqrE7XxB+mT1c74JwGHC+p8Oq2/jHqUUVlx0nqHgicVyi/bK8QC0tCBHUq6qm/TpwzC6HXJvZysdYQYzUe0cm2pqei8raIaaJCpcUn2TxAxbyHFvDgeFm15vAtT689zsHxDoWTiWoN/7nIRNNCt2PT5x3ITfIpYzTaQDR3dACE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792014703; c=relaxed/simple; bh=IpBdc7VdF4MHCTTmvgFMWDBgROijq6bO/OSSW9BxFt4=; h=Date:To:From:Subject:Message-Id; b=fYQsuNjKi4AZq+DvSF+M2AhDOhuMy9OWm3YnGtxPdkmjlHHoa+BBU4jlj7wKUsq1ZsqC+5vPw/jmI1wwLiT7h67uzuGSouRikfoU+7fgvE+Rl4z3NGAUIPzGHDoOTGkhTyl06gEKaU8uJOpDj1wF7LErZVNHy6c0tVR9QEF9ofE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=us76MAKU; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="us76MAKU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7BC771F000C4; Wed, 14 Oct 2026 21:51:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1792014701; bh=FLrjp4FscbAmKjlIYtwlxBX/diiKrPyjDio2dkLoIqY=; h=Date:To:From:Subject; b=us76MAKUPR9Gw7LrFNG10ym2nVhOJYbAOU4ZyPp22lGhBYOtBFPd2tt+O7Ahhh0kD HZwGn94VNUpN0p62u+/NddUu9PuDFptHNzQ7hyRpE6dF/bfTsIYz36HlYiolcvxjAd EcMxRyz5pT2ZCkFr/yAghjsI+PhVT9nEofw2/Kuw= Date: Wed, 14 Oct 2026 14:51:41 -0700 To: mm-commits@vger.kernel.org,vbabka@kernel.org,stable@vger.kernel.org,pfalcato@suse.de,ljs@kernel.org,liam@infradead.org,jannh@google.com,nickolai@csail.mit.edu,akpm@linux-foundation.org From: Andrew Morton Subject: + mm-mlock-use-a-long-for-the-page-count-in-mlock_fixup.patch added to mm-unstable branch Message-Id: <20261014215141.7BC771F000C4@smtp.kernel.org> Precedence: bulk X-Mailing-List: mm-commits@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: The patch titled Subject: mm/mlock: use a long for the page count in mlock_fixup() has been added to the -mm mm-unstable branch. Its filename is mm-mlock-use-a-long-for-the-page-count-in-mlock_fixup.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-mlock-use-a-long-for-the-page-count-in-mlock_fixup.patch This patch will later appear in the mm-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via various branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there most days ------------------------------------------------------ From: Nickolai Zeldovich Subject: mm/mlock: use a long for the page count in mlock_fixup() Date: Wed, 14 Oct 2026 09:13:58 -0400 mlock_fixup() adjusts mm->locked_vm, an unsigned long, by the number of pages whose VM_LOCKED state it changes, but computes that number in an int: int nr_pages; ... nr_pages = (end - start) >> PAGE_SHIFT; ... mm->locked_vm += nr_pages; When a single VMA range of 2^31 pages (8 TiB with 4 KiB pages) or more is locked or unlocked, the count is truncated to 32 bits and then sign-extended, so locked_vm is changed by the wrong amount, while munmap(), mremap() and the other paths that maintain locked_vm use the full unsigned long page count. Such a range is reachable on 64-bit architectures with a 47-bit or larger user address space (x86_64, arm64 with 48-bit VA, riscv64 Sv48) by a task with CAP_IPC_LOCK or a raised RLIMIT_MEMLOCK, which do_mlock() checks against the full untruncated length. It costs nothing with MAP_NORESERVE and MLOCK_ONFAULT/MCL_ONFAULT, since then no page is populated. On x86_64, after p = mmap(NULL, 8UL << 40, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE, -1, 0); mlock2(p, 8UL << 40, MLOCK_ONFAULT); VmLck in /proc/self/status reads 18446744065119617024 kB instead of 8589934592 kB; munmap() of the region then subtracts the true size and leaves VmLck at 18446744056529682432 kB instead of 0. With 16 TiB, locked_vm is not changed at all, VmLck stays 0 kB, and after the task drops CAP_IPC_LOCK or lowers RLIMIT_MEMLOCK, mlock(), mmap(MAP_LOCKED) and the other mlock_future_ok() and account_locked_vm() users enforce RLIMIT_MEMLOCK against that count, so they let the task lock memory beyond its limit (or, in the 8 TiB case, refuse every further lock). The error persists for the life of the mm; unlocking the range in pieces skews it further. The wrong count is per-mm accounting only: it does not change which pages are locked. The int has been there since before git history (the variable was named "pages" until it was renamed in 2.6.28); every other updater of locked_vm uses an unsigned long or long count. Make nr_pages a long, which holds the page count of any user range and its negation, so the existing sign handling is unchanged. Found by formal verification of mm/mlock.c against the kernel binary. Link: https://lore.kernel.org/20261014131358.780240-1-nickolai@csail.mit.edu Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Nickolai Zeldovich Signed-off-by: Andrew Morton Reviewed-by: Pedro Falcato Assisted-by: LLM Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Vlastimil Babka Cc: Jann Horn Cc: --- mm/mlock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/mlock.c~mm-mlock-use-a-long-for-the-page-count-in-mlock_fixup +++ a/mm/mlock.c @@ -457,7 +457,7 @@ static int mlock_fixup(struct vma_iterat { const vma_flags_t old_vma_flags = vma->flags; struct mm_struct *mm = vma->vm_mm; - int nr_pages; + long nr_pages; int ret = 0; if (vma_flags_same_pair(&old_vma_flags, new_vma_flags) || _ Patches currently in -mm which might be from nickolai@csail.mit.edu are mm-mlock-use-a-long-for-the-page-count-in-mlock_fixup.patch