Ted Unangst <t...@tedunangst.com> wrote: > 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.
Or the kernel lock. I remember being told a tiny moment of kernel lock might be cheaper than the read lock, unless I could find someone to understand the cost of vm_map_lock_read_ln. I suppose we are at that moment now.
