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.

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

drop_nlink() warning #632

Closed
behlendorf opened this issue Apr 2, 2012 · 2 comments
Closed

drop_nlink() warning #632

behlendorf opened this issue Apr 2, 2012 · 2 comments
Milestone

Comments

@behlendorf
Copy link
Contributor

Had the following present itself in my kernel logs. Running most
recent zfs/spl rc revision on linux kernel 3.3.0

[409255.817689] WARNING: at fs/inode.c:290 drop_nlink+0x38/0x40()
[409255.817691] Hardware name:
[409255.817693] Modules linked in: zfs(PO) zcommon(PO) znvpair(PO)
zavl(PO) zunicode(PO) spl(O) mpt2sas
[409255.817703] Pid: 10801, comm: rsync Tainted: P O 3.3.0-gentoo #1
[409255.817705] Call Trace:
[409255.817713] [] ? warn_slowpath_common+0x7b/0xc0
[409255.817717] [] ? drop_nlink+0x38/0x40
[409255.817722] [] ? cifs_unlink+0x1fa/0x820
[409255.817727] [] ? handle_pte_fault+0x8a/0x790
[409255.817730] [] ? __d_lookup+0xa3/0x150
[409255.817735] [] ? vfs_unlink+0x8d/0xf0
[409255.817739] [] ? do_unlinkat+0x1a1/0x1d0
[409255.817743] [] ? dput+0x1e/0x190
[409255.817748] [] ? fput+0x162/0x220
[409255.817752] [] ? mntput_no_expire+0x2f/0x180
[409255.817758] [] ? system_call_fastpath+0x16/0x1b

@cwedgwood
Copy link
Contributor

also hit cifs, the fix there: https://lkml.org/lkml/2012/8/31/2
also a rh bugzilla reference: https://bugzilla.redhat.com/show_bug.cgi?id=854050

@behlendorf
Copy link
Contributor Author

Great, thanks for the reference. We can probably close this one out now as not a zfs bug. The above stack was also for cifs.

behlendorf pushed a commit to behlendorf/zfs that referenced this issue May 21, 2018
It is just plain unsafe to peek inside in-kernel
mutex structure and make assumptions about what kernel
does with those internal fields like owner.

Kernel is all too happy to stop doing the expected things
like tracing lock owner once you load a tainted module
like spl/zfs that is not GPL.

As such you will get instant assertion failures like this:

  VERIFY3(((*(volatile typeof((&((&zo->zo_lock)->m_mutex))->owner) *)&
      ((&((&zo->zo_lock)->m_mutex))->owner))) == 
     ((void *)0)) failed (ffff88030be28500 == (null))
  PANIC at zfs_onexit.c:104:zfs_onexit_destroy()
  Showing stack for process 3626
  CPU: 0 PID: 3626 Comm: mkfs.lustre Tainted: P OE ------------ 3.10.0-debug #1
  Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
  Call Trace:
  dump_stack+0x19/0x1b
  spl_dumpstack+0x44/0x50 [spl]
  spl_panic+0xbf/0xf0 [spl]
  zfs_onexit_destroy+0x17c/0x280 [zfs]
  zfsdev_release+0x48/0xd0 [zfs]

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Chunwei Chen <david.chen@osnexus.com>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Closes openzfs#632 
Closes openzfs#633
behlendorf pushed a commit to behlendorf/zfs that referenced this issue May 21, 2018
It is just plain unsafe to peek inside in-kernel
mutex structure and make assumptions about what kernel
does with those internal fields like owner.

Kernel is all too happy to stop doing the expected things
like tracing lock owner once you load a tainted module
like spl/zfs that is not GPL.

As such you will get instant assertion failures like this:

  VERIFY3(((*(volatile typeof((&((&zo->zo_lock)->m_mutex))->owner) *)&
      ((&((&zo->zo_lock)->m_mutex))->owner))) ==
     ((void *)0)) failed (ffff88030be28500 == (null))
  PANIC at zfs_onexit.c:104:zfs_onexit_destroy()
  Showing stack for process 3626
  CPU: 0 PID: 3626 Comm: mkfs.lustre Tainted: P OE ------------ 3.10.0-debug #1
  Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
  Call Trace:
  dump_stack+0x19/0x1b
  spl_dumpstack+0x44/0x50 [spl]
  spl_panic+0xbf/0xf0 [spl]
  zfs_onexit_destroy+0x17c/0x280 [zfs]
  zfsdev_release+0x48/0xd0 [zfs]

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Chunwei Chen <david.chen@osnexus.com>
Reviewed-by: Gvozden Neskovic <neskovic@gmail.com>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Closes openzfs#639
Closes openzfs#632
pcd1193182 pushed a commit to pcd1193182/zfs that referenced this issue Sep 26, 2023
DLPX-83164 zfs hangs when trying to unmount/teardown filesystem
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants