Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

umount fails to return, and fails to un-mount. #10

Closed
lundman opened this issue Apr 16, 2013 · 1 comment
Closed

umount fails to return, and fails to un-mount. #10

lundman opened this issue Apr 16, 2013 · 1 comment

Comments

@lundman
Copy link
Contributor

lundman commented Apr 16, 2013

Currently umounting fails, either nothing happens, or it is stuck in the vnode release code.

Not entirely convinced that zfs_umount is called.

zfs_vfs_unmount(struct mount *mp, int mntflags, vfs_context_t context)
{
    printf("+zfs_umount\n");

# ./cmd.sh zfs umount FROMSOLARIS
Apr  8 16:56:13 lundmans-Mac-Pro kernel[0]: +vnop_fsync
Apr  8 16:56:13 lundmans-Mac-Pro kernel[0]: -vnop_fsync

Entirely possible we have not released a vnode somewhere, all uses of vnode needs to call vnode_put().
@lundman
Copy link
Contributor Author

lundman commented May 3, 2013

This was fixed in an earlier checkin, related to inactive and reclaim logic.

@lundman lundman closed this as completed May 3, 2013
lundman added a commit that referenced this issue Sep 2, 2015
@lundman
Resolve deadlock with namei and cache_purge
b2b7bba 
Which the stack like:
    frame #2: 0xffffff800292e4a5 kernel`cache_purge
    frame #3: 0xffffff7f83281ee8 zfs`zfs_vnop_reclaim + 152
    frame #4: 0xffffff80029468f0 kernel`vclean
    frame #6: 0xffffff80029463cb kernel`vnode_reclaim_internal
    frame #9: 0xffffff800293f4b6 kernel`vnode_create
    frame #10: 0xffffff7f83283c41 zfs`zfs_znode_getvnode + 513
    frame #11: 0xffffff7f83288d78 zfs`zfs_zget_internal + 984
    frame #12: 0xffffff7f832764c9 zfs`zfs_vfs_vget + 329
    frame #13: 0xffffff800293979d kernel`namei

It would seem vnop_reclaim can not call into VFS again as it already
holds locks, and verifying with hfs_vnop_reclaim, they do not
call cache_purge().
lundman added a commit that referenced this issue Sep 3, 2015
@lundman
Resolve deadlock with namei and cache_purge
6909c10 
Which the stack like:
    frame #2: 0xffffff800292e4a5 kernel`cache_purge
    frame #3: 0xffffff7f83281ee8 zfs`zfs_vnop_reclaim + 152
    frame #4: 0xffffff80029468f0 kernel`vclean
    frame #6: 0xffffff80029463cb kernel`vnode_reclaim_internal
    frame #9: 0xffffff800293f4b6 kernel`vnode_create
    frame #10: 0xffffff7f83283c41 zfs`zfs_znode_getvnode + 513
    frame #11: 0xffffff7f83288d78 zfs`zfs_zget_internal + 984
    frame #12: 0xffffff7f832764c9 zfs`zfs_vfs_vget + 329
    frame #13: 0xffffff800293979d kernel`namei

It would seem vnop_reclaim can not call into VFS again as it already
holds locks, and verifying with hfs_vnop_reclaim, they do not
call cache_purge().
lundman added a commit that referenced this issue Oct 21, 2015
@lundman @ilovezfs
Resolve deadlock with namei and cache_purge
b21ec21 
Which the stack like:
    frame #2: 0xffffff800292e4a5 kernel`cache_purge
    frame #3: 0xffffff7f83281ee8 zfs`zfs_vnop_reclaim + 152
    frame #4: 0xffffff80029468f0 kernel`vclean
    frame #6: 0xffffff80029463cb kernel`vnode_reclaim_internal
    frame #9: 0xffffff800293f4b6 kernel`vnode_create
    frame #10: 0xffffff7f83283c41 zfs`zfs_znode_getvnode + 513
    frame #11: 0xffffff7f83288d78 zfs`zfs_zget_internal + 984
    frame #12: 0xffffff7f832764c9 zfs`zfs_vfs_vget + 329
    frame #13: 0xffffff800293979d kernel`namei

It would seem vnop_reclaim can not call into VFS again as it already
holds locks, and verifying with hfs_vnop_reclaim, they do not
call cache_purge().
@rottegift rottegift mentioned this issue Nov 18, 2015
Open
lundman added a commit that referenced this issue Jan 23, 2017
@lundman
Resolve deadlock with namei and cache_purge
3f611ce 
Which the stack like:
    frame #2: 0xffffff800292e4a5 kernel`cache_purge
    frame #3: 0xffffff7f83281ee8 zfs`zfs_vnop_reclaim + 152
    frame #4: 0xffffff80029468f0 kernel`vclean
    frame #6: 0xffffff80029463cb kernel`vnode_reclaim_internal
    frame #9: 0xffffff800293f4b6 kernel`vnode_create
    frame #10: 0xffffff7f83283c41 zfs`zfs_znode_getvnode + 513
    frame #11: 0xffffff7f83288d78 zfs`zfs_zget_internal + 984
    frame #12: 0xffffff7f832764c9 zfs`zfs_vfs_vget + 329
    frame #13: 0xffffff800293979d kernel`namei

It would seem vnop_reclaim can not call into VFS again as it already
holds locks, and verifying with hfs_vnop_reclaim, they do not
call cache_purge().
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@lundman