aboutsummaryrefslogtreecommitdiffstats
path: root/include/linux
diff options
context:
space:
mode:
authorOleg Drokin <[email protected]>2017-08-02 14:45:16 -0400
committerBrian Behlendorf <[email protected]>2017-08-02 11:45:16 -0700
commitd89616fda88bc030aaff758d37ede7d35e58841a (patch)
tree6947a3a0b235e62cad3187573f6205e7593e36fe /include/linux
parenteed143dfa6af0e004d0239bd3297b30e45b8c4d3 (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