Deadlock in nullfs/zfs somewhere

[Andriy Gapon]

Kostik,

thank you for being patient with me and explaining details of the contract and
inner workings of VFS suspend.

As we discussed out-of-band, unfortunately, it seems that it is impossible to
implement the same contract for ZFS.  The reason is that ZFS filesystems appear
as many independent filesystems, but in reality they share a common pool.  So
suspending a single filesystem does not suspend the pool and that is contrary to
current VFS suspend concept.

Additionally, ZFS needs a "full" suspend mechanism that would prevent both read
and write access from VFS layer.  The current VFS suspend mechanism suspend
writes / modifications only.

I am not sure how to reconcile the differences...
Here is a number of rough ideas.  I will highly appreciate your opinion and
suggestions.

Idea #1.
Add a new suspend type to VFS layer that would correspond to the needs of ZFS.
This is quite laborious as it would require adding vn_start_read calls in many
places.  Also, making two kinds of VFS suspend play nice with each other could
be non-trivial.

Idea #2.
This is perhaps an ugly approach, but I already have it implemented locally.
The idea is to re-use / abuse vnode locking as a ZFS suspend barrier.
(This can be considered to be analogous to putting vn_start_op() / vn_end_op()
into vop_lock / vop_unlock).
That is, ZFS would override VOP_LOCK/VOP_UNLOCK to check for internal
suspension.  The necessary care would be taken to respect all locking flags
including LK_NOWAIT.  Recursive entry would have to be supported too.

Idea #3.
Provide some other mechanism to expose ZFS suspension state to VFS.  And then
use that mechanism to avoid blocking on calls to ZFS in the strategic /
sensitive places like vlrureclaim(), vtryrecycle(), etc.

-- 
Andriy Gapon