> On Dec 8, 2021, at 12:24, Martin Pieuchot <[email protected]> wrote: > > On 06/12/21(Mon) 14:58, Scott Cheloha wrote: >> On Mon, Dec 06, 2021 at 08:35:15PM +0100, Mark Kettenis wrote: >>>> Date: Sun, 5 Dec 2021 18:01:04 -0600 >>>> From: Scott Cheloha <[email protected]> >>>> >>>> Two things in sys_kbind() need an explicit kernel lock. First, >>>> sigexit(). Second, uvm_map_extract(), because the following call >>>> chain panics without it: >>>> >>>> [...] >>>> >>>> With this committed we can unlock kbind(2). >>>> >>>> Thoughts? ok? >>> >>> To be honest, I don't think this makes sense unless you can make the >>> "normal" code path lock free. You're replacing a single >>> KERNEL_LOCK/UNLOCK pair with (potentially) a bunch of them. That may >>> actually make things worse. So I think we need to make >>> uvm_map_extract() mpsafe first. >> >> Unlocking uvm_map_extract() would improve things, yes. > > Yes, please. What's missing?
uvm_map_extract() calls uvm_mapent_clone() which calls the pgo_reference function for the new map entry's underlying object if it has one. All of those reference functions require the kernel lock. Your UVM Object Locking patch clears that up.
