aboutsummaryrefslogtreecommitdiff
path: root/sys/i386/linux/linux_locore.asm
diff options
context:
space:
mode:
authorMark Johnston <markj@FreeBSD.org>2019-07-30 17:09:58 +0000
committerMark Johnston <markj@FreeBSD.org>2019-07-30 17:09:58 +0000
commit49c3e8c8d147e0f23a41e3d7f8a6a8c1dba0c29d (patch)
treef7cc343264c7eff5b2b36668472701bf5e8e5999 /sys/i386/linux/linux_locore.asm
parent98197770c9f7c46a2cf2d50305b3f119d97a823e (diff)
downloadsrc-49c3e8c8d147e0f23a41e3d7f8a6a8c1dba0c29d.tar.gz
src-49c3e8c8d147e0f23a41e3d7f8a6a8c1dba0c29d.zip
Enable witness(4) blessings.
witness has long had a facility to "bless" designated lock pairs. Lock order reversals between a pair of blessed locks are not reported upon. We have a number of long-standing false positive LOR reports; start marking well-understood LORs as blessed. This change hides reports about UFS vnode locks and the UFS dirhash lock, and UFS vnode locks and buffer locks, since those are the two that I observe most often. In the long term it would be preferable to be able to limit blessings to a specific site where a lock is acquired, and/or extend witness to understand why some lock order reversals are valid (for example, if code paths with conflicting lock orders are serialized by a third lock), but in the meantime the false positives frequently confuse users and generate bug reports. Reviewed by: cem, kib, mckusick MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D21039
Notes
Notes: svn path=/head/; revision=350450
Diffstat (limited to 'sys/i386/linux/linux_locore.asm')
0 files changed, 0 insertions, 0 deletions