struct uvm_map's .addr is protected by the map's lock and .{min,max}_offset
are immutable.
uvm_map_inherit() locks the VM map upon entry, sets the desired inheritance
mode for the given address range (validated outside the lock) and unlocks
the map itself.
fork(2), i.e. uvm_mapent_forkcopy(), first locks both old and new maps and
then copies entries over as per the inheritance type.
futex(2), another user of struct vm_map_entry's .inheritance member, also
locks the map accordingly.
I don't see a reason to grab the kernel lock here anymore.
This has been running fine through regress and daily usage on my X230 driver
for months, incl. selected ports builds.
Feedback? Objection? Tests? OK?
Index: syscalls.master
===================================================================
RCS file: /cvs/src/sys/kern/syscalls.master,v
retrieving revision 1.237
diff -u -p -r1.237 syscalls.master
--- syscalls.master 30 Nov 2022 10:20:37 -0000 1.237
+++ syscalls.master 30 Nov 2022 20:42:48 -0000
@@ -445,7 +445,7 @@
247 UNIMPL
248 UNIMPL
249 UNIMPL
-250 STD { int sys_minherit(void *addr, size_t len, \
+250 STD NOLOCK { int sys_minherit(void *addr, size_t len, \
int inherit); }
251 OBSOL rfork
252 STD { int sys_poll(struct pollfd *fds, \
