Diego Nieto Cid, le mar. 24 juin 2025 14:39:35 +0100, a ecrit:
> On Mon, Jun 23, 2025 at 12:51:23AM +0200, Samuel Thibault wrote:
> > > + err = vm_deallocate(mach_task_self(), mem, M_512M);
> > > + ASSERT_RET(err, "deallocation failed");
> >
> > It would be also useful to check that trying to vm_protect the PROT_NONE
> > into PROT_ALL fails when that comes above the limit.
> >
>
> I'm tackling this test and I'm finding some trouble to implement it.
> Currently, the patch performs the calculation of PROT_NONE size based
> on the entry's max protection.
>
> So, if I want to test for the promotion from PROT_NONE to PROT_ALL, I
> need to set the current protection to NONE and the max protection to ALL.
>
> This is a test in between or for preparation to the one you suggested
> but that I thought it would work:
>
> printf("check that allocation promotions from PROT_NONE to PROT_ALL
> account for the limit\n");
> err = vm_map(mach_task_self(),
> &mem, M_512M, 0, 0, MACH_PORT_NULL, 0, 1,
> VM_PROT_NONE, VM_PROT_ALL, VM_INHERIT_COPY);
> ASSERT_RET(err, "allocation failed");
> /* test, again, that PROT_NONE maps do no decrease the limit */
> err = vm_allocate(mach_task_self(), &mem2, M_512M, TRUE);
> ASSERT_RET(err, "allocating memory below the limit must succeed");
> ^
> |
> +----- this fails because vm_map used up 512M which weren't accounted as
> NONE due to its max protection being VM_PROT_ALL
>
> My guess is that I should account every page with current protection (instead
> of
> max protection) set to VM_PROT_NONE and keep track of updates through
> vm_protect.
No, that's not what we want.
> I don't remember why it was implemented against the max protection
Because that is what Linux implements: RLIMIT_AS limits what
mmap(PROT_NONE) can allocate. Then, changing with mprotect() will not
change the RLIMIT_AS counting.
Samuel
