Process stuck in "vnread"

[Konstantin Belousov]

On Mon, Mar 28, 2016 at 08:52:03AM -0700, Maxim Sobolev wrote:
> Done some head scratching, it looks like it's got page fault in the
> copyin() (cp(1) AFAIK mmaps source file). There might be some interlock
> issue between competing write to the same ZFS, the md0 device is locked
> forever waiting for the write operation to complete at the very same time.
> I am curious as to whether we are allowed to sleep in the dmu_write_uio_dbuf(),
> AFAIK dmu is ZFS's transaction layer, so maybe copyin() should be done
> earlier to avoid possible page fault in there?

No idea about ZFS, but if the issue is due to copyin(9) recursing into
VM and then VFS while owning file system locks, it is well-known and
long-standing issue. I sometimes call it 'ups deadlock', for some
reasons, see tools/test/upsdl/ for the distilled test case.

It is handled for UFS and NFS, read the long comment starting with 'The
vn_io_fault() is a wrapper' in sys/kern/vfs_vnops.c, which describes the
deadlock in details and explains the mechanism which is used to prevent
it. Filesystems must opt-in into it by specifiying MNTK_NO_IOPF flag,
and then being ready to get an array of pages for io instead of the buffer
KVA.