On 3/27/24 11:41, Joao Martins wrote:
On 25/03/2024 13:52, Jason Gunthorpe wrote:
On Mon, Mar 25, 2024 at 12:17:28PM +0000, Joao Martins wrote:
However, I am not smart enough to figure out why ...
Apparently, from the source, mmap() fails to allocate pages on the desired address:
1746 assert((uintptr_t)self->buffer % HUGEPAGE_SIZE == 0);
1747 vrc = mmap(self->buffer, variant->buffer_size, PROT_READ |
PROT_WRITE,
1748 mmap_flags, -1, 0);
→ 1749 assert(vrc == self->buffer);
1750
But I am not that deep into the source to figure our what was intended and what
went
wrong :-/
I can SKIP() the test rather assert() in here if it helps. Though there are
other tests that fail if no hugetlb pages are reserved.
But I am not sure if this is problem here as the initial bug email had an
enterily different set of failures? Maybe all you need is an assert() and it
gets into this state?
I feel like there is something wrong with the kselftest framework,
there should be some way to fail the setup/teardown operations without
triggering an infinite loop :(
I am now wondering if the problem is the fact that we have an assert() in the
middle of FIXTURE_{TEST,SETUP} whereby we should be having ASSERT_TRUE() (or any
other kselftest macro that). The expect/assert macros from kselftest() don't do
asserts and it looks like we are failing mid tests in the assert().
Maybe it is OK for setup_sizes(), but maybe not OK for the rest (i.e. during the
actual setup / tests). I can throw a patch there to see if this helps Mirsad.
Well, we are in the job of making the kernel better and as bug free as we can.
Maybe we should not delve too much into detail: is this a kernel bug, or the kselftest
program bug?
Some people already mentioned that I might have sysctl variable problems. I don't see
what the mmap() HUGEPAGE allocation at fixed address was meant to prove?
Thanks,
Mirsad
