Recently, I am reading the memory management part of linux kernel code (the version I am reading is 4.10). I find that mremap is strange.

In short, sys_mremap() will call move_vma(), which basically will do the following:

1. copy_vma()
2. move_page_tables()
3. do_munmap()

The step 1 and 2 are easy to understand, they just copy from the old memory mapping into the new mapping. However, they do not increment the refcount of struct page while copying to new memory mapping in these two steps (I do not find it in source code).

Then in step 3, kernel will unmap the old mappings. It iterates every vma and every pages, decrement the refcount of struct page and finally call tlb_flush_mmu_free() to free all pages.

My question is:
1. if the kernel implement mremap like this, the following access to the pages will cause page fault?
2. why kernel does not increment the refcount when move_vma()? It will keep pages in memory after mremap and will not casue the unnecessary page fault.
3. What about anonymous and private mapped pages? How can user access the content after this kind of pages has been freed?

Just so you are aware.
Very few if any distros still use the kernels that are older than 5.10. Thus the code you are reading is very out-of-date and much has changed. The current kernel version being worked on today is 6.4 and most of the distros are using either a very late 5.X version or the early 6.X versions.

Although some things are still the same, much has been updated. Working with a newer version will be closer to the present code levels.

I understand that and any explaination to my question based on newer linux version is fine. I post the code version I am reading just for clarity. And the mremap() is a relatively stable syscall, so the implementation might not changed too much in newer version.

It seems to me this would be better off in the Programming forum.
You can ask the Mods to move it via the 'Report' button.

Obviously it works, there was no any problem with memory management. I think you need to go deep into the details to understand how does it really work.
https://docs.kernel.org/admin-guide/mm/index.html. From my side it is not an easy topic.
I don't understand why should it increment refcount in case of a move.
by the way, this document has a nice picture about the call graph (page 73)
This is definitely documented and explained. Otherwise I don't really understand this question, if a page is freed it is not in use and cannot be accessed by apps - if I understand well.

https://unix.stackexchange.com/quest...physical-pages

What move_vma() actually does is

(1) create a new mapping at destination.
(2) copy old mapping from source to the new mapping created in (1).
(3) unmap old mapping.

But the code shows that it will decrement refcount of struct page at (3) but does not increment the refcount of struct page at (1) or (2). So after move_vma(), there is still a memory mapping (at destination) needs those pages but it has been cleaned in step (3).

So I wonder why kernel does not increment refcount of struct page in (1) or (2), so after the decrement in (3) the pages will not be freed.

So as I explained, the struct page has been freed in (3) and the physical memory page's content may disappear. If it is an anonymous and private pages, there is no place to find the memory content if user access it through the new mapping after calling sys_mremap().


Thanks for your reply and discussion！