Page MenuHomeFreeBSD

Enhance support for Linux mremap system call
Needs ReviewPublic

Authored by chuck on Mar 24 2018, 7:29 PM.



This review is to get feedback / advice on a work-in-progress version of the Linux mremap system call.

Test Plan

Passes Linux Test Project's (ltp) mremap syscall tests except for mremap04

Diff Detail

rS FreeBSD src repository
Lint Skipped
Unit Tests Skipped
Build Status
Buildable 15785

Event Timeline

chuck created this revision.Mar 24 2018, 7:29 PM
jeff added inline comments.Mar 24 2018, 7:35 PM

There may not be a 1:1 mapping between entries and address ranges specified by users. If there is any incompatibility in the range the kernel will break it up into multiple entries. I'm not 100% positive, but we may also make multiple entries for other reasons of internal convenience that may not be user initiated. Look at the various map related calls for examples of walking through entries in a loop.


This may work but it makes me a little uncomfortable to use a kernel syscall interface directly like this. It also will potentially invalidate the map_entry structure you looked up before.

Since you dropped the vm_map lock another thread could race and modify the entry so this won't be done in a multi-thread safe way. If another thread in the process touches an address in either of these ranges it may see in-between state. You should grab a write lock on the map and implement these stages as a single atomic operation.


Similar issue to the above. You've more or less implemented this as syscalls within the kernel instead of using the direct kernel interfaces. It's likely that you may end up with a compatible API but none of the performance benefits. If you just want compatibility without atomicity or performance you could do this whole thing in userspace.

Can you expose this to the fbsd API as well (for source compatibility with Linux software)

emaste added a subscriber: emaste.Jun 9 2018, 7:18 PM
trasz added a subscriber: trasz.Feb 26 2019, 4:07 PM
chuck added a comment.May 1 2019, 1:32 PM


Yeah, I got distracted by other things, but promise to work on this at BSDCan.

trasz added a comment.EditedJun 19 2019, 12:01 AM

FWIW, trying to run apt-get autoremove results in:

panic: vm_page_free_prep: freeing mapped page 0xfffff802357f2240

#11 0xffffffff80bc53f3 in panic (fmt=0xffffffff81e88898 <cnputs_mtx> "\033\247.\201\377\377\377\377") at /usr/home/trasz/svn/head/sys/kern/kern_shutdown.c:832
#12 0xffffffff80f0c7fe in vm_page_free_prep (m=0xfffff802357f2240) at /usr/home/trasz/svn/head/sys/vm/vm_page.c:3292
#13 0xffffffff80f08462 in vm_page_free_toq (m=0xfffff802357f2240) at /usr/home/trasz/svn/head/sys/vm/vm_page.c:3531
#14 0xffffffff80f0381b in vm_object_terminate_pages (object=<optimized out>) at /usr/home/trasz/svn/head/sys/vm/vm_object.c:726
#15 vm_object_terminate (object=0xfffff80065854300) at /usr/home/trasz/svn/head/sys/vm/vm_object.c:798
#16 0xffffffff80f02b82 in vm_object_deallocate (object=0xfffff80065854300) at /usr/home/trasz/svn/head/sys/vm/vm_object.c:663
#17 0xffffffff80ef6b1f in vm_map_entry_deallocate (entry=<optimized out>, system_map=0) at /usr/home/trasz/svn/head/sys/vm/vm_map.c:3461
#18 vm_map_process_deferred () at /usr/home/trasz/svn/head/sys/vm/vm_map.c:586
#19 0xffffffff80f009b2 in kern_munmap (td=0xfffff80005ebb000, addr0=<optimized out>, size=1048576) at /usr/home/trasz/svn/head/sys/vm/vm_mmap.c:572
#20 0xffffffff828930a5 in linux_mremap (td=0xfffff80005ebb000, args=0xfffff80005ebb3c8) at /usr/home/trasz/svn/head/sys/compat/linux/linux_misc.c:699
#21 0xffffffff81091916 in syscallenter (td=0xfffff80005ebb000) at /usr/home/trasz/svn/head/sys/amd64/amd64/../../kern/subr_syscall.c:135
#22 amd64_syscall (td=0xfffff80005ebb000, traced=0) at /usr/home/trasz/svn/head/sys/amd64/amd64/trap.c:1181