Re: uvm_map_inentry() & KERNEL_LOCK()

2019-11-01 Thread Mark Kettenis
> Date: Fri, 1 Nov 2019 14:13:26 +0100 > From: Martin Pieuchot > > On 01/11/19(Fri) 13:12, Mark Kettenis wrote: > > > From: "Ted Unangst" > > > 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 >

Re: uvm_map_inentry() & KERNEL_LOCK()

2019-11-01 Thread Theo de Raadt
Mark Kettenis wrote: > > From: "Ted Unangst" > > 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 > > > > > >

Re: uvm_map_inentry() & KERNEL_LOCK()

2019-11-01 Thread Martin Pieuchot
On 01/11/19(Fri) 13:12, Mark Kettenis wrote: > > From: "Ted Unangst" > > 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 > > >

Re: uvm_map_inentry() & KERNEL_LOCK()

2019-11-01 Thread Mark Kettenis
> Date: Fri, 1 Nov 2019 00:18:43 +0100 > From: Martin Pieuchot > > When a userland program triggers a fault or does a syscall its SP and/or > PC are checked to be sure they are in expected regions. The result of > this check is cached in the "struct proc" such that a lookup isn't > always

Re: uvm_map_inentry() & KERNEL_LOCK()

2019-11-01 Thread Mark Kettenis
> From: "Ted Unangst" > 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 ||

Re: uvm_map_inentry() & KERNEL_LOCK()

2019-10-31 Thread Theo de Raadt
Ted Unangst 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) > >

Re: uvm_map_inentry() & KERNEL_LOCK()

2019-10-31 Thread Ted Unangst
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

Re: uvm_map_inentry() & KERNEL_LOCK()

2019-10-31 Thread Theo de Raadt
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

uvm_map_inentry() & KERNEL_LOCK()

2019-10-31 Thread Martin Pieuchot
When a userland program triggers a fault or does a syscall its SP and/or PC are checked to be sure they are in expected regions. The result of this check is cached in the "struct proc" such that a lookup isn't always necessary. Currently when the cache is outdated the KERNEL_LOCK() is taken