Deadlock between nfsd and snapshots.
Kostik Belousov
kostikbel at gmail.com
Mon Aug 21 13:38:58 UTC 2006
On Mon, Aug 21, 2006 at 01:21:51PM +0000, Tor Egge wrote:
>
> I wrote:
>
> > The deadlock indicates that one or more of IN_CHANGE, IN_MODIFIED or
> > IN_UPDATE was set on the inode, indicating a write operation
> > (e.g. VOP_WRITE(), VOP_RENAME(), VOP_CREATE(), VOP_REMOVE(), VOP_LINK(),
> > VOP_SYMLINK(), VOP_SETATTR(), VOP_MKDIR(), VOP_RMDIR(), VOP_MKNOD()) that was
> > not protected by vn_start_write() or vn_start_secondary_write().
>
> The most common "write" operation was probably VOP_GETATTR().
>
> ufs_itimes(), called from ufs_getattr(), might set the IN_MODIFIED inode flag
> if IN_ACCESS is set on the inode even if neither IN_CHANGE nor IN_UPDATE is
> set, transitioning the inode flags into a state where ufs_inactive() calls the
> blocking variant of vn_start_secondary_write().
>
> calling ufs_itimes() with only a shared vnode lock might cause unsafe accesses
> to the inode flags. Setting of IN_ACCESS at the end of ffs_read() and
> ffs_extread() might also be unsafe. If DIRECTIO is enabled then O_DIRECT reads
> might not even attempt to set the IN_ACCESS flag.
Thanks for analysis !
I already thought about ufs_itimes/GETATTR. I am currently musing about
storing the list of threads that called vm_start_write in the mount struct,
and checking that the current thread is on list during modifying operations,
at least that ops that set the IN_* flags.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20060821/e8282794/attachment.pgp
More information about the freebsd-fs
mailing list