CC @kib, @alc... I know that getpagesizes(3) predates these mechanisms for requesting superpage allocations, but I wonder if it'd be useful to note in the manpage that the presence of larger page sizes in the result does not imply that superpage shmfds are supported.

tests/sys/posixshm/memfd_test.c
299	`atf_tc_skip` makes more sense here than letting the subsequent requirement fail, since the exact size doesn't matter when it's ENOTTY that we got back. I'd probably also probably word it as "large page requests are not ...", since the platform does seem to support implicit promotion.

Applied feedback. I'll change the commit msg shortly to reflect that it's a skip now.

Harbormaster completed remote builds in B73511: Diff 178833.Thu, May 28, 4:47 PM

siva retitled this revision from memfd_test: expect fail hugetlb when largepages are not supported to memfd_test: skip hugetlb testcase when large page requests are not supported.Thu, May 28, 4:48 PM

Are the test changes good to go here?

Yeah, that's fine. Technically there's some utility in letting it run to the end, but that logic is broken because pscnt > 1 but we can't create large page shmfds. Let's ship the skip and if I can find a good way to test it on such a system, I'll fix that logic to make sure that it's working right.

This revision is now accepted and ready to land.Wed, Jun 10, 11:55 PM

Closed by commit rG64b053f879a8: memfd_test: skip hugetlb testcase when large page requests are not supported (authored by siva). · Explain WhyThu, Jun 11, 12:15 AM

This revision was automatically updated to reflect the committed changes.

siva added a commit: rG64b053f879a8: memfd_test: skip hugetlb testcase when large page requests are not supported.

In D57289#1318520, @kevans wrote:

Yeah, that's fine. Technically there's some utility in letting it run to the end, but that logic is broken because pscnt > 1 but we can't create large page shmfds. Let's ship the skip and if I can find a good way to test it on such a system, I'll fix that logic to make sure that it's working right.

I'm a bit confused: there shouldn't be any problem with creating largepages on riscv, pmap_enter() supports psind > 0. Where exactly is ENOTTY coming from?

In D57289#1318652, @markj wrote:

In D57289#1318520, @kevans wrote:

Yeah, that's fine. Technically there's some utility in letting it run to the end, but that logic is broken because pscnt > 1 but we can't create large page shmfds. Let's ship the skip and if I can find a good way to test it on such a system, I'll fix that logic to make sure that it's working right.

I'm a bit confused: there shouldn't be any problem with creating largepages on riscv, pmap_enter() supports psind > 0. Where exactly is ENOTTY coming from?

My assumption is that it was https://elixir.bootlin.com/freebsd/v15.0/source/sys/kern/uipc_shm.c#L1169, riscv defines it to 0 because it doesn't support non-transparent creation of superpages, apparently:

https://elixir.bootlin.com/freebsd/v15.0/source/sys/riscv/include/vmparam.h#L253

In D57289#1318660, @kevans wrote:

In D57289#1318652, @markj wrote:

In D57289#1318520, @kevans wrote:

Yeah, that's fine. Technically there's some utility in letting it run to the end, but that logic is broken because pscnt > 1 but we can't create large page shmfds. Let's ship the skip and if I can find a good way to test it on such a system, I'll fix that logic to make sure that it's working right.

I'm a bit confused: there shouldn't be any problem with creating largepages on riscv, pmap_enter() supports psind > 0. Where exactly is ENOTTY coming from?

My assumption is that it was https://elixir.bootlin.com/freebsd/v15.0/source/sys/kern/uipc_shm.c#L1169, riscv defines it to 0 because it doesn't support non-transparent creation of superpages, apparently:

https://elixir.bootlin.com/freebsd/v15.0/source/sys/riscv/include/vmparam.h#L253