Process stuck in "vnread"

[Peter Holm]

On Wed, Mar 02, 2016 at 01:57:07PM +0200, Konstantin Belousov wrote:
> On Wed, Mar 02, 2016 at 03:02:02AM -0800, Maxim Sobolev wrote:
> > About the backtrace, indeed, looks like you are right and some portion of
> > it is not decoded properly, as it's loaded as a kernel module. The setup is
> > somewhat even more complicated, the /usr/ports is mounted via NULLFS, so in
> > this command:
> > 
> > cp /usr/local/share/automake-1.15/compile ./compile
> > 
> > The target (i.e. ./compile) here is a path on ZFS that is exported via
> > NULLFS, while the source is a file on UFS2->md->ZFS. This is probably the
> > reason stack trace is incomplete, both zfs.ko and nullfs.ko are loaded as
> > modules and the next few frames point towards those. Unfortunately I cannot
> > beat kgdb to read symbols from those .ko's and decode them.
> 
> Is nullfs mount put over ZFS only ?  The backtrace you shown cannot
> happen for ZFS, since ZFS has its own pager vop.  In fact, I would
> agree that the backtrace is reasonable for nullfs over UFS upper vnode.
> The following patch should fix the 'paging while faulting on uiomove'
> issue for nullfs over UFS.
> 
> Peter, could you, please, test the patch ?  It is purely nullfs change,
> and the most interesting situation is the ups' deadlock, but the whole
> set of nullfs tests would be good to check.
> 
> diff --git a/sys/fs/nullfs/null_vfsops.c b/sys/fs/nullfs/null_vfsops.c
> index 64e1e29..49bae28 100644
> --- a/sys/fs/nullfs/null_vfsops.c

I have tested this patch with all of the nullfs scenarios I have,
multiple times.
I also tested the UPS' scenario on nullfs without finding any problems.

- Peter