Deadlock in nullfs/zfs somewhere

Konstantin Belousov kostikbel at gmail.com
Fri Jul 19 10:30:29 UTC 2013


On Fri, Jul 19, 2013 at 01:18:31PM +0300, Andriy Gapon wrote:
> on 18/07/2013 21:52 Konstantin Belousov said the following:
> > There is VFS method VFS_SUSP_CLEAN, called when the suspension is
> > lifted.  UFS uses it to clean the back-queue of work which were
> > not performed during the suspend, mostly inactivate the postponed
> > inactive vnodes.  ZFS probably does not need it, since it does
> > not check for MNTK_SUSPEND, but if it starts care, there is a place
> > to put the code.
> 
> I will keep this in mind.
> 
> > On the other hand, I believe that your patch is notoriously incomplete,
> > because there should be a lot of threads which mutate ZFS mounts state
> > and which do not call vn_start_write() around the mutations.  I.e.
> > all ZFS top-level code which calls into ZFS ops and which is not
> > coming from VFS.
> 
> I agree.  What I am trying to fix right now is VFS<->ZFS interaction.  I think
> that ZFS<->ZFS should already be fine - it's protected by internal ZFS locking.
> OTOH, perhaps my understanding of what you said is incomplete or incorrect,
> because VFS suspension mechanism is completely unknown to me yet.
> 
I think that you should satisfy the VFS invariants, and prevent mutators
from operating on the filesystem when MNTK_SUSPEND is set, for the
case mutators are running outside the context where VFS could call
vn_start_write() around.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20130719/866d16f4/attachment.sig>


More information about the freebsd-fs mailing list