On 18/12/22(Sun) 20:55, Martin Pieuchot wrote:
> On 17/12/22(Sat) 14:15, David Hill wrote:
> > 
> > 
> > On 10/28/22 03:46, Renato Aguiar wrote:
> > > Use of bbolt Go library causes 7.2 to freeze. I suspect it is triggering 
> > > some
> > > sort of deadlock in mmap because threads get stuck at vmmaplk.
> > > 
> > > I managed to reproduce it consistently in a laptop with 4 cores 
> > > (i5-1135G7)
> > > using one unit test from bbolt:
> > > 
> > >    $ doas pkg_add git go
> > >    $ git clone https://github.com/etcd-io/bbolt.git
> > >    $ cd bbolt
> > >    $ git checkout v1.3.6
> > >    $ go test -v -run TestSimulate_10000op_10p
> > > 
> > > The test never ends and this is the 'top' report:
> > > 
> > >    PID      TID PRI NICE  SIZE   RES STATE     WAIT      TIME    CPU 
> > > COMMAND
> > > 32181   438138 -18    0   57M   13M idle      uvn_fls   0:00  0.00% 
> > > bbolt.test
> > > 32181   331169  10    0   57M   13M sleep/1   nanoslp   0:00  0.00% 
> > > bbolt.test
> > > 32181   497390  10    0   57M   13M idle      vmmaplk   0:00  0.00% 
> > > bbolt.test
> > > 32181   380477  14    0   57M   13M idle      vmmaplk   0:00  0.00% 
> > > bbolt.test
> > > 32181   336950  14    0   57M   13M idle      vmmaplk   0:00  0.00% 
> > > bbolt.test
> > > 32181   491043  14    0   57M   13M idle      vmmaplk   0:00  0.00% 
> > > bbolt.test
> > > 32181   347071   2    0   57M   13M idle      kqread    0:00  0.00% 
> > > bbolt.test
> > > 
> > > After this, most commands just hang. For example, running a 'ps | grep 
> > > foo' in
> > > another shell would do it.
> > > 
> > 
> > I can reproduce this on MP, but not SP.  Here is /trace from ddb after using
> > the ddb.trigger sysctl.  Is there any other information I could pull from
> > DDB that may help?
> 
> Thanks for the useful report David! 
> 
> The issue seems to be a deadlock between the `vmmaplk' and a particular
> `vmobjlock'.  uvm_map_clean() calls uvn_flush() which sleeps with the
> `vmmaplk' held. 
> 
> I'll think a bit about this and try to come up with a fix ASAP.

I'm missing a piece of information.  All the threads in your report seem
to want a read version of the `vmmaplk' so they should not block.  Could
you reproduce the hang with a WITNESS kernel and print 'show all locks'
in addition to all the informations you've reported?

Reply via email to