> From: "Ted Unangst" <t...@tedunangst.com> > Date: Fri, 01 Nov 2019 00:18:35 -0400 > > Theo de Raadt wrote: > > In uvm_map_inentry_fix(), two variables in the map are now being read > > without a per-map read lock, this was previously protected by the > > kernel lock > > > > if (addr < map->min_offset || addr >= map->max_offset) > > return (FALSE); > > > > When I wrote this I was told to either use KERNEL_LOCK() or > > vm_map_lock_read(), which is vm_map_lock_read_ln() .. if > > KERNEL_LOCK() is no longer good should vm_map_lock_read be moved > > upwards, or are you confident those offsets are safe to read > > independently without any locking?? > > indeed, another thread can expand the map, so that should have the read lock.
That can't happen. The map limits are only touched by uvm_map_setup() and uvmspace_exec(). The former is when the map gets created and isn't known to other threads yet. The latter is called from exec(2) and the process is guaranteed to be single-threaded at that point.
