Re: [PATCH v6 6/6] selftests/mm: add a GUP selftest

Mike Rapoport <[email protected]> Tue, 4 Aug 2026 12:35:26 +0300
Newsgroups gmane.linux.documentation,gmane.linux.kernel.mm,gmane.linux.kernel
Message-ID <[email protected]>
Hi Sarthak,

On Tue, Aug 04, 2026 at 01:08:05PM +0530, Sarthak Sharma wrote:
> Hi Mike!
> 
> On 8/3/26 2:30 PM, Mike Rapoport wrote:
> >> Add a new GUP selftest which uses kselftest_harness.h. Cover
> >> 12 mapping configurations: THP enabled, THP disabled and
> >> HugeTLB, each across private/shared mappings and with/without
> >> FOLL_WRITE. Run 7 testcases for every variant: get_user_pages,
> >> get_user_pages_fast, pin_user_pages, pin_user_pages_fast,
> >> pin_user_pages_longterm, and DUMP_USER_PAGES_TEST using both
> >> get and pin.
> >>
> >> Sweep four nr_pages_per_call values for each test: 1, 512, 123 and
> >> all pages. This preserves the coverage previously provided by
> >> run_gup_matrix(): 12 mapping combinations x 5 GUP/PUP operations x 4
> >> batch sizes, for 240 ioctl calls. The two dump modes add another 96
> >> calls.
> >>
> >> Preserve the previous sparse dump coverage with a standalone test for
> >> pages 0, 19 and 0x1000. In total the selftest reports 85 TAP
> >> cases and issues 337 ioctls.
> >>
> >> Add the new gup binary to the selftests/mm build, .gitignore,
> >> run_vmtests.sh and MAINTAINERS. Update
> >> Documentation/core-api/pin_user_pages.rst for the new test.
> >>
> >> Suggested-by: David Hildenbrand (Arm) <[email protected]>
> >> Signed-off-by: Sarthak Sharma <[email protected]>
> >>
> >> +
> >> +FIXTURE_SETUP(gup_test)
> >> +{
> >> +	int mmap_flags = MAP_PRIVATE;
> >> +	int zero_fd;
> >> +	char *p;
> >> +
> >> +	/* zero_fd has to be >= 0. Already checked in main() */
> >> +	zero_fd = open("/dev/zero", O_RDWR);
> >> +	ASSERT_GE(zero_fd, 0);
> >> +
> >> +	/* gup_fd has to be >= 0. Already checked in main() */
> >> +	self->gup_fd = open(GUP_TEST_FILE, O_RDWR);
> >> +	ASSERT_GE(self->gup_fd, 0);
> >> +
> >> +	self->size = variant->hugetlb ? 256 * MB : 128 * MB;
> > 
> > I'd derive the hugetbl variant size from the size of a huge page and
> > predefined number of huge pages.
> > 
> 
> I was following the existing logic that run_gup_matrix() had. I can
> implement this. Any suggestions what number of huge pages we can fix?

You currently use 128 hugepages for the most common case of 2M default huge
page, so setting, say, NR_HUGEPAGES to 128 seems reasonable.

Later we could extend this to better deal with other huge page sizes.

-- 
Sincerely yours,
Mike.