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

Files appear as Directories in new SA code #9

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

Files appear as Directories in new SA code #9

lundman opened this issue Apr 16, 2013 · 1 comment
Labels
bug

Comments

@lundman
Copy link
Contributor

lundman commented Apr 16, 2013

We are not setting vnode's vtype correctly somewhere in the new SA code, or possibly the z_mode, or vap_type.

-rwxr-xr-x  1 lundman  staff  490131 Apr 16  2013 configure
# cp configure /BOOM/
# ls -la /BOOM
drwxr-xr-x  30610 root  wheel   512 Apr  8 16:53 configure
@lundman
Copy link
Contributor Author

lundman commented Apr 17, 2013

3d69230

@lundman lundman closed this as completed Apr 17, 2013
@jollyjinx jollyjinx mentioned this issue Dec 2, 2014
Closed
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().
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
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@lundman