On Wed, May 18, 2022 at 07:42:32PM -0600, Theo de Raadt wrote: > Mark Kettenis <mark.kette...@xs4all.nl> wrote: > > > > Isn't the vm_map_lock enough? > > > > Could be. The fast path is going to take that lock anyway. This > > would require a bit of surgery to uvm_map_extract() to make sure we > > don't take the vm_map_lock twice. Worth exploring I'd say. > > I think the vm_map_lock can be dropped before it reaches that code, > because of 3 cases: (1) new kbind lock, (2) a repeated kbind lock and > return, or (3) violation and process termination. > > So before doing the copyin() and updates, simply vm_map_unlock() > > Will that work and isn't it simpler than David's proposal?
I'm not super familiar with uvm so it's hard for me to say it would or wouldn't be simpler, but my initial impressions are that it would be a lot more surgery and I wouldn't be confident I did such changes right. Releasing a lock and then taking it again quickly can have undesirable consequences too. If something else is waiting on the rwlock, releasing it will wake them up, but they will probably lose because we've already taken it again.
