re: vrele vs. syncer deadlock

[matthew green <mrg%eterna.com.au@localhost>]

> > Some time ago I unconditionally removed LK_NOWAIT from vn_lock().
> > Suppose we need this patch:
> >
> > RCS file: /cvsroot/src/sys/ufs/ffs/ffs_vfsops.c,v
> > retrieving revision 1.341
> > diff -p -u -2 -r1.341 ffs_vfsops.c
> > --- ffs_vfsops.c        20 Oct 2016 19:31:32 -0000      1.341
> > +++ ffs_vfsops.c        12 Dec 2016 09:45:17 -0000
> > @@ -1918,5 +1918,6 @@ ffs_sync(struct mount *mp, int waitfor,
> >          while ((vp = vfs_vnode_iterator_next(marker, ffs_sync_selector, &ctx)))
> >          {
> > -               error = vn_lock(vp, LK_EXCLUSIVE);
> > +               error = vn_lock(vp, LK_EXCLUSIVE |
> > +                   (waitfor == MNT_LAZY ? LK_NOWAIT : 0));
> >                  if (error) {
> >                          vrele(vp);
> >
> > Is it reproducible so you can test it?
> 
> I can't reproduce it easily. Others (mrg@ and roy@) seem to have more 
> luck finding a workload to trigger the page freelist problem on erlite
> 
> Also, I saw the dh@ thought more was needed?

the problem i see on erlite is not going to be fixed by any fix
in the filesystem.  that problem is because the freelist used to
allocate pool pages is empty yet uvmexp.free is in the high
1000s.  the pdaemon says "nothing to do" and goes back to sleep.
the waiters wake up, once again alloc fail, wake up pdaemon and
go back to sleep.  repeats forever.


.mrg.