Re: [PATCH 1/1] mm/page_table_check: widen map counters

[Andrew Morton <akpm@linux-foundation.org>]

On Sat, 18 Jul 2026 12:27:20 +0800 Ren Wei <enjou1224z@gmail.com> wrote:

> From: Zhiling Zou <roxy520tt@gmail.com>
> 
> page_table_check_set() and page_table_check_clear() store per-page
> anonymous and file map counts in signed atomic_t counters. A page can
> have more than INT_MAX read-only mappings while still being mapped
> legally.
> 
> The global zero page is one example: repeated read faults on private
> anonymous mappings install read-only PTEs that are accounted as file
> mappings. Once file_map_count wraps, the next set or clear observes a
> negative count and trips BUG_ON(), allowing an unprivileged user to panic
> a kernel with CONFIG_PAGE_TABLE_CHECK enabled.
> 
> Use atomic64_t for both counters so page_table_check can keep the same
> type-conflict checks without overflowing at INT_MAX mappings.

Thanks.

> Fixes: df4e817b7108 ("mm: page table check")
> Cc: stable@vger.kernel.org
>
> ...
>
> index 53a8997ec043..edd9d9edf6fc 100644
> --- a/mm/page_table_check.c
> +++ b/mm/page_table_check.c
> @@ -14,8 +14,8 @@
>  #define pr_fmt(fmt)	"page_table_check: " fmt
>  
>  struct page_table_check {
> -	atomic_t anon_map_count;
> -	atomic_t file_map_count;
> +	atomic64_t anon_map_count;
> +	atomic64_t file_map_count;
>  };

AI review suggest this might cause problems in, of all places, page_ext.c:

	https://sashiko.dev/#/patchset/b4414b588418c52a99d959d35a40e064ae8b6e72.1784337674.git.roxy520tt@gmail.com

My googling indicates that a 64-bit atomic op on a 32-bit-aligned
address is probably usually OK, but it doesn't sound smart.

Probably adding __aligned(sizeof(atomic64_t)) will address?