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