Re: WITNESS panic: acquiring blockable sleep lock with spinlock or critical section held (rwlock) kmmaplk

On 20/12/20(Sun) 20:55, Mark Kettenis wrote: > > Date: Sat, 19 Dec 2020 18:07:41 -0300 > > From: Martin Pieuchot > > > > On 18/12/20(Fri) 08:04, Todd C. Miller wrote: > > > On Fri, 18 Dec 2020 13:34:39 +0100, Mark Kettenis wrote: > > > > > > > Anyway, your analysis is right. When a kernel

Re: WITNESS panic: acquiring blockable sleep lock with spinlock or critical section held (rwlock) kmmaplk

> Date: Sat, 19 Dec 2020 18:07:41 -0300 > From: Martin Pieuchot > > On 18/12/20(Fri) 08:04, Todd C. Miller wrote: > > On Fri, 18 Dec 2020 13:34:39 +0100, Mark Kettenis wrote: > > > > > Anyway, your analysis is right. When a kernel thread wants to use > > > pmap_extract(9) on a userland pmap,

Re: WITNESS panic: acquiring blockable sleep lock with spinlock or critical section held (rwlock) kmmaplk

On Sat, 19 Dec 2020 18:07:41 -0300, Martin Pieuchot wrote: > A solution based on a comment and a non-enabled by option seems very > fragile to me. I came up with the idea of poisoning the ipl of the > mutex. What do you think? Even better. OK millert@ - todd

Re: WITNESS panic: acquiring blockable sleep lock with spinlock or critical section held (rwlock) kmmaplk

On 18/12/20(Fri) 08:04, Todd C. Miller wrote: > On Fri, 18 Dec 2020 13:34:39 +0100, Mark Kettenis wrote: > > > Anyway, your analysis is right. When a kernel thread wants to use > > pmap_extract(9) on a userland pmap, it needs to lock pm_apte_mtx to > > prevent another thread from simultaniously

Re: WITNESS panic: acquiring blockable sleep lock with spinlock or critical section held (rwlock) kmmaplk

On Fri, 18 Dec 2020 13:34:39 +0100, Mark Kettenis wrote: > Anyway, your analysis is right. When a kernel thread wants to use > pmap_extract(9) on a userland pmap, it needs to lock pm_apte_mtx to > prevent another thread from simultaniously activating a userland pmap > too. So indeed,

Re: WITNESS panic: acquiring blockable sleep lock with spinlock or critical section held (rwlock) kmmaplk

> Date: Thu, 17 Dec 2020 19:25:44 -0300 > From: Martin Pieuchot > > On 17/12/20(Thu) 23:16, Mark Kettenis wrote: > > > Date: Thu, 17 Dec 2020 18:56:52 -0300 > > > From: Martin Pieuchot > > > > > > On 16/12/20(Wed) 22:49, Greg Steuck wrote: > > > > I just hit this while booting an i386-current

Re: WITNESS panic: acquiring blockable sleep lock with spinlock or critical section held (rwlock) kmmaplk

On 17/12/20(Thu) 23:16, Mark Kettenis wrote: > > Date: Thu, 17 Dec 2020 18:56:52 -0300 > > From: Martin Pieuchot > > > > On 16/12/20(Wed) 22:49, Greg Steuck wrote: > > > I just hit this while booting an i386-current in vmd. The source tree is > > > synced to "Remove the assertion in

Re: WITNESS panic: acquiring blockable sleep lock with spinlock or critical section held (rwlock) kmmaplk

> Date: Thu, 17 Dec 2020 18:56:52 -0300 > From: Martin Pieuchot > > On 16/12/20(Wed) 22:49, Greg Steuck wrote: > > I just hit this while booting an i386-current in vmd. The source tree is > > synced to "Remove the assertion in uvm_km_pgremove()." > > > > I enabled WITNESS on top of GENERIC.

Re: WITNESS panic: acquiring blockable sleep lock with spinlock or critical section held (rwlock) kmmaplk

On 16/12/20(Wed) 22:49, Greg Steuck wrote: > I just hit this while booting an i386-current in vmd. The source tree is > synced to "Remove the assertion in uvm_km_pgremove()." > > I enabled WITNESS on top of GENERIC. Naturally, GENERIC-Dec15 snap works. > > Anybody else see this so I know it's

WITNESS panic: acquiring blockable sleep lock with spinlock or critical section held (rwlock) kmmaplk

I just hit this while booting an i386-current in vmd. The source tree is synced to "Remove the assertion in uvm_km_pgremove()." I enabled WITNESS on top of GENERIC. Naturally, GENERIC-Dec15 snap works. Anybody else see this so I know it's worth a bisect? OpenBSD 6.8-current (WITNESS) #0: Tue