From: Wake Liu via ltp <ltp@lists.linux.it>
To: ltp@lists.linux.it
Cc: kaleshsingh@google.com
Subject: [LTP] [PATCH 3/4] ioctl10: Compare vma_page_size with KernelPageSize from smaps
Date: Wed, 11 Nov 2026 09:31:50 +0000 [thread overview]
Message-ID: <20261111093151.374731-4-wakel@google.com> (raw)
In-Reply-To: <20261111093151.374731-1-wakel@google.com>
PROCMAP_QUERY returns in vma_page_size the page size the kernel uses to
back the VMA, i.e. vma_kernel_pagesize(), which /proc/$PID/smaps shows
as KernelPageSize. The test compares it with getpagesize() instead,
which is only correct as long as the kernel page size equals the page
size reported to userspace.
That is not the case with the 16K page size emulation that Android uses
on x86_64, where the kernel keeps using 4K pages internally:
TFAIL: q->vma_page_size (4096) != getpagesize() (16384)
Compare it with KernelPageSize of the same VMA in /proc/self/smaps
instead. This also cross-checks the two kernel interfaces, the same way
the other fields are checked against /proc/self/maps. Nothing changes
on kernels where both page sizes are equal.
Signed-off-by: Wake Liu <wakel@google.com>
---
testcases/kernel/syscalls/ioctl/ioctl10.c | 34 ++++++++++++++++++++++-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/testcases/kernel/syscalls/ioctl/ioctl10.c b/testcases/kernel/syscalls/ioctl/ioctl10.c
index 8a4f8ae40..5dd2a866d 100644
--- a/testcases/kernel/syscalls/ioctl/ioctl10.c
+++ b/testcases/kernel/syscalls/ioctl/ioctl10.c
@@ -28,6 +28,7 @@
#include "lapi/ioctl.h"
#define PROC_MAP_PATH "/proc/self/maps"
+#define PROC_SMAPS_PATH "/proc/self/smaps"
struct map_entry {
unsigned long vm_start;
@@ -86,6 +87,37 @@ static void parse_maps_file(const char *filename, const char *keyword, struct ma
tst_brk(TFAIL, "parse maps file /proc/self/maps failed");
}
+/*
+ * vma_page_size is the page size the kernel uses to back the VMA, which is
+ * reported as KernelPageSize in /proc/self/smaps. It is not necessarily
+ * equal to getpagesize(), e.g. for hugetlb mappings or when the kernel
+ * reports a larger page size to userspace than it uses internally.
+ */
+static unsigned long get_kernel_page_size(unsigned long vm_start)
+{
+ FILE *fp = SAFE_FOPEN(PROC_SMAPS_PATH, "r");
+ unsigned long start, end, size_kb;
+ char line[1024];
+ int found = 0;
+
+ while (fgets(line, sizeof(line), fp)) {
+ if (sscanf(line, "%lx-%lx ", &start, &end) == 2) {
+ found = start == vm_start;
+ continue;
+ }
+
+ if (found && sscanf(line, "KernelPageSize: %lu kB", &size_kb) == 1) {
+ SAFE_FCLOSE(fp);
+ return size_kb * 1024;
+ }
+ }
+
+ SAFE_FCLOSE(fp);
+ tst_brk(TBROK, "KernelPageSize of %lx not found in %s",
+ vm_start, PROC_SMAPS_PATH);
+ return 0;
+}
+
static void verify_ioctl(void)
{
struct map_entry entry;
@@ -107,7 +139,7 @@ static void verify_ioctl(void)
TST_EXP_EQ_LU(q->vma_flags, entry.vm_flags);
TST_EXP_EQ_LU(q->vma_start, entry.vm_start);
TST_EXP_EQ_LU(q->vma_end, entry.vm_end);
- TST_EXP_EQ_LU(q->vma_page_size, getpagesize());
+ TST_EXP_EQ_LU(q->vma_page_size, get_kernel_page_size(entry.vm_start));
TST_EXP_EQ_LU(q->vma_offset, entry.vm_pgoff);
TST_EXP_EQ_LU(q->inode, entry.vm_inode);
TST_EXP_EQ_LU(q->dev_major, entry.vm_major);
--
2.56.0.567.gdb80ae8cd5-goog
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2026-11-11 9:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 9:31 [LTP] [PATCH 0/4] Don't derive kernel granularities from getpagesize() Wake Liu via ltp
2026-11-11 9:31 ` [LTP] [PATCH 1/4] epoll_wait06, fcntl35: Don't assume a pipe buffer is getpagesize() Wake Liu via ltp
2026-11-11 9:31 ` [LTP] [PATCH 2/4] memcg, userfaultfd07: Populate whole pages instead of single bytes Wake Liu via ltp
2026-11-11 9:31 ` Wake Liu via ltp [this message]
2026-11-11 9:31 ` [LTP] [PATCH 4/4] signal06: Allocate the alternate signal stack with mmap() Wake Liu via ltp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261111093151.374731-4-wakel@google.com \
--to=ltp@lists.linux.it \
--cc=kaleshsingh@google.com \
--cc=wakel@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox