Mark Kettenis <[email protected]> wrote: > > From: "Ted Unangst" <[email protected]> > > 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.
Ah, ok then.
