Page MenuHomeFreeBSD

Enhance support for Linux mremap system call
Needs ReviewPublic

Authored by chuck on Mar 24 2018, 7:29 PM.
Tags
None
Referenced Files
Unknown Object (File)
Dec 20 2023, 4:10 AM
Unknown Object (File)
Jul 10 2023, 3:29 AM
Unknown Object (File)
May 14 2023, 6:22 AM
Unknown Object (File)
Apr 25 2023, 9:33 AM

Details

Reviewers
jeff
dchagin
Summary

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

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

Event Timeline

sys/compat/linux/linux_misc.c
679

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.

698–700

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.

756–757

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)

Ping

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

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