]> granicus.if.org Git - spl/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)
committerTony Hutter <hutter2@llnl.gov>
Thu, 3 Aug 2017 19:12:31 +0000 (12:12 -0700)
commiteb23d329c4515d776ef5eb688aebdbd06cc7a615
treefae8fe09a988c9f91419e1d501f1c58b4ea068e0
parent48fcbbb2459db0e81a3274292c7313ac5064ddc0
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