]> git.proxmox.com Git - mirror_spl.git/commit
Remove misguided HAVE_MUTEX_OWNER check, take 2
authorOleg Drokin <green@linuxhacker.ru>
Wed, 2 Aug 2017 18:45:16 +0000 (14:45 -0400)
committerBrian Behlendorf <behlendorf1@llnl.gov>
Thu, 3 Aug 2017 03:50:27 +0000 (20:50 -0700)
commit98cdcb8286db2dadf369a22d33a53e49b11e3288
tree9be5551d2ec26bfe23cbcdff27da54b8ea6bd29f
parent261a3151e16851304eb3e36af2681d1d1579b08f
Remove misguided HAVE_MUTEX_OWNER check, take 2

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 #639
Closes #632
config/spl-build.m4
include/sys/mutex.h