diff options
author | Oleg Drokin <[email protected]> | 2017-08-02 14:45:16 -0400 |
---|---|---|
committer | Brian Behlendorf <[email protected]> | 2017-08-02 11:45:16 -0700 |
commit | d89616fda88bc030aaff758d37ede7d35e58841a (patch) | |
tree | 6947a3a0b235e62cad3187573f6205e7593e36fe /include/linux | |
parent | eed143dfa6af0e004d0239bd3297b30e45b8c4d3 (diff) |
Remove misguided HAVE_MUTEX_OWNER check
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 <[email protected]>
Reviewed-by: Chunwei Chen <[email protected]>
Signed-off-by: Oleg Drokin <[email protected]>
Closes #632
Closes #633
Diffstat (limited to 'include/linux')
0 files changed, 0 insertions, 0 deletions