Re: mmap: Do not push KERNEL_LOCK() too far

2020-10-05 Thread Mark Kettenis
> Date: Mon, 5 Oct 2020 11:25:39 +0200 > From: Martin Pieuchot > > On 03/10/20(Sat) 12:59, Mark Kettenis wrote: > > > Date: Fri, 2 Oct 2020 10:32:27 +0200 > > > From: Martin Pieuchot > > > > > > On 01/10/20(Thu) 21:44, Mark Kettenis wrote: > > > > > Date: Thu, 1 Oct 2020 14:10:56 +0200 > > > >

Re: mmap: Do not push KERNEL_LOCK() too far

2020-10-05 Thread Martin Pieuchot
On 03/10/20(Sat) 12:59, Mark Kettenis wrote: > > Date: Fri, 2 Oct 2020 10:32:27 +0200 > > From: Martin Pieuchot > > > > On 01/10/20(Thu) 21:44, Mark Kettenis wrote: > > > > Date: Thu, 1 Oct 2020 14:10:56 +0200 > > > > From: Martin Pieuchot > > > > > > > > While studying a bug report from

Re: mmap: Do not push KERNEL_LOCK() too far

2020-10-03 Thread Mark Kettenis
> Date: Fri, 2 Oct 2020 10:32:27 +0200 > From: Martin Pieuchot > > On 01/10/20(Thu) 21:44, Mark Kettenis wrote: > > > Date: Thu, 1 Oct 2020 14:10:56 +0200 > > > From: Martin Pieuchot > > > > > > While studying a bug report from naddy@ in 2017 when testing guenther@'s > > > amap/anon locking

Re: mmap: Do not push KERNEL_LOCK() too far

2020-10-02 Thread Martin Pieuchot
On 01/10/20(Thu) 21:44, Mark Kettenis wrote: > > Date: Thu, 1 Oct 2020 14:10:56 +0200 > > From: Martin Pieuchot > > > > While studying a bug report from naddy@ in 2017 when testing guenther@'s > > amap/anon locking diff I figured out that we have been too optimistic in > > the !MAP_ANON case. >

Re: mmap: Do not push KERNEL_LOCK() too far

2020-10-01 Thread Mark Kettenis
> Date: Thu, 1 Oct 2020 14:10:56 +0200 > From: Martin Pieuchot > > While studying a bug report from naddy@ in 2017 when testing guenther@'s > amap/anon locking diff I figured out that we have been too optimistic in > the !MAP_ANON case. > > The reported panic involves, I'd guess, a race between

mmap: Do not push KERNEL_LOCK() too far

2020-10-01 Thread Martin Pieuchot
While studying a bug report from naddy@ in 2017 when testing guenther@'s amap/anon locking diff I figured out that we have been too optimistic in the !MAP_ANON case. The reported panic involves, I'd guess, a race between fd_getfile() and vref(): panic: vref used where vget required