Your message dated Wed, 17 Nov 2021 02:03:46 +0800
with message-id 
<CAMr=8w4gnifs+m_69odpgc+bge4nw7trkoycrnntb9uot2q...@mail.gmail.com>
and subject line 
has caused the Debian Bug report #994855,
regarding zfs-dkms: Panic when receiving, fixed upstream
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
994855: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994855
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: zfs-dkms
Version: 2.0.3-9
Severity: grave
Tags: patch upstream
Justification: causes non-serious data loss

With this latest version of the debian package, I've  been getting
panics receiving datasets. There's a patch already merged upstream. The
errors are:

VERIFY3(insert_inode_locked(ip) == 0) failed (-16 == 0)
PANIC at zfs_znode.c:616:zfs_znode_alloc()

The patch is at
https://github.com/openzfs/zfs/commit/afa7b3484556d3ae610a34582ce5ebd2c3e27bba

Please cherrypick this and add it soon.


-- System Information:
Debian Release: 11.0
  APT prefers stable
  APT policy: (700, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-0.bpo.5-amd64 (SMP w/32 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages zfs-dkms depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  dkms                   2.8.4-3
ii  file                   1:5.39-3
ii  libc6-dev [libc-dev]   2.31-13
ii  libpython3-stdlib      3.9.2-3
ii  lsb-release            11.1.0
ii  perl                   5.32.1-4
ii  python3-distutils      3.9.2-1

Versions of packages zfs-dkms recommends:
ii  linux-libc-dev  5.10.46-4
ii  zfs-zed         2.0.3-9
ii  zfsutils-linux  2.0.3-9

Versions of packages zfs-dkms suggests:
ii  debhelper  13.3.4

-- debconf information excluded
>From afa7b3484556d3ae610a34582ce5ebd2c3e27bba Mon Sep 17 00:00:00 2001
From: Paul Zuchowski <[email protected]>
Date: Fri, 11 Jun 2021 20:00:33 -0400
Subject: [PATCH] Do not hash unlinked inodes

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.

Reviewed-by: Brian Behlendorf <[email protected]>
Reviewed-by: Alan Somers <[email protected]>
Signed-off-by: Paul Zuchowski <[email protected]>
Closes #9741
Closes #11223
Closes #11648
Closes #12210
---
 module/os/linux/zfs/zfs_znode.c | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

Index: zfs-linux-2.0.3/module/os/linux/zfs/zfs_znode.c
===================================================================
--- zfs-linux-2.0.3.orig/module/os/linux/zfs/zfs_znode.c
+++ zfs-linux-2.0.3/module/os/linux/zfs/zfs_znode.c
@@ -610,17 +610,24 @@ zfs_znode_alloc(zfsvfs_t *zfsvfs, dmu_bu
         * 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:
>From afa7b3484556d3ae610a34582ce5ebd2c3e27bba Mon Sep 17 00:00:00 2001
From: Paul Zuchowski <[email protected]>
Date: Fri, 11 Jun 2021 20:00:33 -0400
Subject: [PATCH] Do not hash unlinked inodes

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.

Reviewed-by: Brian Behlendorf <[email protected]>
Reviewed-by: Alan Somers <[email protected]>
Signed-off-by: Paul Zuchowski <[email protected]>
Closes #9741
Closes #11223
Closes #11648
Closes #12210
---
 module/os/linux/zfs/zfs_znode.c | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

Index: zfs-linux-2.0.3/module/os/linux/zfs/zfs_znode.c
===================================================================
--- zfs-linux-2.0.3.orig/module/os/linux/zfs/zfs_znode.c
+++ zfs-linux-2.0.3/module/os/linux/zfs/zfs_znode.c
@@ -610,17 +610,24 @@ zfs_znode_alloc(zfsvfs_t *zfsvfs, dmu_bu
         * 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:

--- End Message ---
--- Begin Message ---
Source-Version: 2.0.6-1

Mark as fixed in 2.0.6-1 update.

Regards,
Aron

--- End Message ---

Reply via email to