Skip to content

Commit

Permalink
Do not hash unlinked inodes
Browse files Browse the repository at this point in the history
In zfs_znode_alloc we always hash inodes.  If the
znode is unlinked, we do not need to hash it.  This
fixes the problem where zfs_suspend_fs is doing zrele
(iput) in an async fashion, and zfs_resume_fs unlinked
drain processing will try to hash an inode that could
still be hashed, resulting in a panic.

Fixes: openzfs#9741
Fixes: openzfs#11223
Fixes: openzfs#11648

Signed-off-by: Paul Zuchowski <pzuchowski@datto.com>
  • Loading branch information
PaulZ-98 committed Jun 9, 2021
1 parent bd82264 commit e7c606a
Showing 1 changed file with 11 additions and 4 deletions.
15 changes: 11 additions & 4 deletions module/os/linux/zfs/zfs_znode.c
Original file line number Diff line number Diff line change
Expand Up @@ -606,17 +606,24 @@ zfs_znode_alloc(zfsvfs_t *zfsvfs, dmu_buf_t *db, int blksz,
* number is already hashed for this super block. This can never
* happen because the inode numbers map 1:1 with the object numbers.
*
* The one exception is rolling back a mounted file system, but in
* this case all the active inode are unhashed during the rollback.
* Exceptions include rolling back a mounted file system, either
* from the zfs rollback or zfs recv command.
*
* Active inodes are unhashed during the rollback, but since zrele
* can happen asynchronously, we can't guarantee they've been
* unhashed. This can cause hash collisions in unlinked drain
* processing so do not hash unlinked znodes.
*/
VERIFY3S(insert_inode_locked(ip), ==, 0);
if (links > 0)
VERIFY3S(insert_inode_locked(ip), ==, 0);

mutex_enter(&zfsvfs->z_znodes_lock);
list_insert_tail(&zfsvfs->z_all_znodes, zp);
zfsvfs->z_nr_znodes++;
mutex_exit(&zfsvfs->z_znodes_lock);

unlock_new_inode(ip);
if (links > 0)
unlock_new_inode(ip);
return (zp);

error:
Expand Down

0 comments on commit e7c606a

Please sign in to comment.