vm/mman: handle properly munmap of chunks larger than SIZE_PAGE

[badochov]

JIRA: RTOS-893

Description

Munmap handled badly segments bigger that SIZE_PAGE, after it the rb tree was in corrupted state.

Motivation and Context

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Chore (refactoring, style fixes, git/CI config, submodule management, no code logic changes)

How Has This Been Tested?

• Already covered by automatic testing.
• New test added: (add PR link here).
• Tested by hand on: ia-32

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing linter checks and tests passed.
• My changes generate no new compilation warnings for any of the targets.

Special treatment

• This PR needs additional PRs to work mprotect: fix mapEntrySplit #581
• I will merge this PR by myself when appropriate.

[github-actions]

Unit Test Results

7 723 tests  +23   7 008 ✅ +23   37m 41s ⏱️ +24s
  443 suites + 7     715 💤 ± 0 
    1 files   ± 0       0 ❌ ± 0 

Results for commit 7fab743. ± Comparison against base commit 1f9ea40.

This pull request removes 1 and adds 24 tests. Note that renamed tests count towards both.

phoenix-rtos-tests/psh/touch ‑ armv7m7-imxrt117x-evk:phoenix-rtos-tests/psh/touch

phoenix-rtos-tests/mem/mmap ‑ armv7a7-imx6ull-evk:phoenix-rtos-tests/mem/mmap.test_mmap.len__not_page_aligned
phoenix-rtos-tests/mem/mmap ‑ armv7a7-imx6ull-evk:phoenix-rtos-tests/mem/mmap.test_mmap.len__not_page_aligned_file
phoenix-rtos-tests/mem/mmap ‑ armv7a7-imx6ull-evk:phoenix-rtos-tests/mem/mmap.test_mmap.len__zero
phoenix-rtos-tests/mem/mmap ‑ armv7a9-zynq7000-qemu:phoenix-rtos-tests/mem/mmap.test_mmap.len__not_page_aligned
phoenix-rtos-tests/mem/mmap ‑ armv7a9-zynq7000-qemu:phoenix-rtos-tests/mem/mmap.test_mmap.len__not_page_aligned_file
phoenix-rtos-tests/mem/mmap ‑ armv7a9-zynq7000-qemu:phoenix-rtos-tests/mem/mmap.test_mmap.len__zero
phoenix-rtos-tests/mem/mmap ‑ armv7a9-zynq7000-zedboard:phoenix-rtos-tests/mem/mmap.test_mmap.len__not_page_aligned
phoenix-rtos-tests/mem/mmap ‑ armv7a9-zynq7000-zedboard:phoenix-rtos-tests/mem/mmap.test_mmap.len__not_page_aligned_file
phoenix-rtos-tests/mem/mmap ‑ armv7a9-zynq7000-zedboard:phoenix-rtos-tests/mem/mmap.test_mmap.len__zero
phoenix-rtos-tests/mem/mmap ‑ armv7m4-stm32l4x6-nucleo:phoenix-rtos-tests/mem/mmap.test_mmap.len__not_page_aligned
…

♻️ This comment has been updated with latest results.

[agkaminski]

Perhaps we could use vm_mapEntrySplit in case of the "in the middle" munmap

[badochov]

Perhaps we could use vm_mapEntrySplit in case of the "in the middle" munmap

Only thing that comes to my mind is changing this part to

			s = map_alloc();
			/* This case if only possible if an unmapped region is in the middle of a single entry,
			 * so there is no possibility of partially unmapping. */
			if (s == NULL) {
				return -ENOMEM;
			}
			vm_mapEntrySplit(proc, map, e, s, overlapStart);
			continue; /* Process in next iteration. */

What do you think about it?

[agkaminski]

Perhaps we could use vm_mapEntrySplit in case of the "in the middle" munmap

Only thing that comes to my mind is changing this part to

			s = map_alloc();
			/* This case if only possible if an unmapped region is in the middle of a single entry,
			 * so there is no possibility of partially unmapping. */
			if (s == NULL) {
				return -ENOMEM;
			}
			vm_mapEntrySplit(proc, map, e, s, overlapStart);
			continue; /* Process in next iteration. */

What do you think about it?

Looks nice!

[agkaminski]

LGTM

[badochov]

@agkaminski @damianloew
unix-socket test failed on CI on armv7a-qemu due to timeout 358ms instead of 350ms, should I be concerned?
Munmap changes should change this test, as in poll and gettime theres no munmap

https://github.com/phoenix-rtos/phoenix-rtos-kernel/actions/runs/11050286361/job/30697841405?pr=578

[agkaminski]

@agkaminski @damianloew unix-socket test failed on CI on armv7a-qemu due to timeout 358ms instead of 350ms, should I be concerned? Munmap changes should change this test, as in poll and gettime theres no munmap

https://github.com/phoenix-rtos/phoenix-rtos-kernel/actions/runs/11050286361/job/30697841405?pr=578

I guess it did pass on the rerun. @damianloew perhaps this timeout is somewhat on the edge?

[damianloew]

@agkaminski @damianloew unix-socket test failed on CI on armv7a-qemu due to timeout 358ms instead of 350ms, should I be concerned? Munmap changes should change this test, as in poll and gettime theres no munmap
https://github.com/phoenix-rtos/phoenix-rtos-kernel/actions/runs/11050286361/job/30697841405?pr=578

I guess it did pass on the rerun. @damianloew perhaps this timeout is somewhat on the edge?

Yeah, we had a similar problem some time ago and changed the value to 350 from 310:
phoenix-rtos/phoenix-rtos-tests#350

We will consider increasing the value more - probably we will check 400. However I am not sure whether higher values are caused by our system or by the gh machine on which the tests are executed