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

recordsize-irregular write()s causes panic #12

Closed
lundman opened this issue May 2, 2013 · 1 comment
Closed

recordsize-irregular write()s causes panic #12

lundman opened this issue May 2, 2013 · 1 comment
Labels
bug

Comments

@lundman
Copy link
Contributor

lundman commented May 2, 2013

Default recordsize of 131072
dd using bs=10000
panic:

#6  0xffffff7f80eacaa8 in dmu_buf_hold_array_by_dnode (dn=0xffffff8007ebac00, offset=100000, length=31072, read=0, tag=0xffffff7f80fa1f68, numbufsp=0xffffff80469dba7c, dbpp=0xffffff80469dba80, flags=0) at dmu.c:395
395                             zfs_panic_recover("zfs: accessing past end of object 15/9 (size=100352, access 100000+31072)

Which appears to be from

        if (offset + length > dn->dn_datablksz) {
            zfs_panic_recover("zfs: accessing past end of object "
                "%llx/%llx (size=%u access=%llu+%llu)",

because for some reason, dn->dn_datablksz is 100352, when one would expect 131072.
@lundman
Copy link
Contributor Author

lundman commented May 2, 2013

https://github.com/zfs-osx/zfs/blob/master/module/zfs/zfs_znode.c#L1606

Replaced commented out code, fixes this issue.

    dmu_object_size_from_db(sa_get_db(zp->z_sa_hdl), &zp->z_blksz, &dummy);

@lundman lundman closed this as completed May 2, 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().
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