Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge pull request #1 from openbsd/master #8

Closed
wants to merge 1 commit into from
Closed

Merge pull request #1 from openbsd/master #8

wants to merge 1 commit into from

Conversation

niamtokik
Copy link

merge from openbsd master

merge from openbsd master
@niamtokik niamtokik closed this Jan 8, 2019
@niamtokik niamtokik reopened this Jan 8, 2019
@niamtokik niamtokik closed this Jan 8, 2019
bob-beck pushed a commit that referenced this pull request Feb 7, 2019
This lets witness(4) save a stack trace on each lock acquisition.
The saved traces can be viewed in ddb(4) when showing the currently
held locks, which may help when debugging incorrect locking.

Sample output:

ddb{0}> show all locks
Process 63836 (rm) thread 0xffff8000221e52c8 (435004)
exclusive rrwlock inode r = 0 (0xfffffd8119a092c0) locked @ /usr/src/sys/ufs/ufs/ufs_vnops.c:1547
#0  witness_lock+0x419
#1  _rw_enter+0x2bb
#2  _rrw_enter+0x42
#3  VOP_LOCK+0x3f
#4  vn_lock+0x36
#5  vfs_lookup+0xa1
#6  namei+0x2b3
#7  dounlinkat+0x85
#8  syscall+0x338
#9  Xsyscall+0x128
exclusive kernel_lock &kernel_lock r = 1 (0xffffffff81e6a5f0) locked @ /usr/src/sys/arch/amd64/amd64/intr.c:525
#0  witness_lock+0x419
#1  syscall+0x2b6
#2  Xsyscall+0x128

The saving adds overhead, so it is not enabled by default. It can be
taken into use by setting sysctl kern.witness.locktrace=1 at runtime
or by defining WITNESS_LOCKTRACE in the kernel configuration.

Feedback and OK anton@
bbamsch pushed a commit to bbamsch/openbsd that referenced this pull request Oct 12, 2019
bob-beck pushed a commit that referenced this pull request Jan 8, 2020
necessary because other threads cannot access the data structure.
This fixes the following lock order issue:

witness: lock order reversal:
 1st 0xfffffd81d821d248 fdlock (&newfdp->fd_fd.fd_lock)
 2nd 0xffff800000fe45b8 primlk (&prime_fpriv->lock)
lock order "&prime_fpriv->lock"(rwlock) -> "&newfdp->fd_fd.fd_lock"(rwlock) first seen at:
#0  witness_checkorder+0x449
#1  rw_enter_write+0x43
#2  dma_buf_fd+0x8c
#3  drm_gem_prime_handle_to_fd+0xed
#4  drmioctl+0xdc
#5  VOP_IOCTL+0x55
#6  vn_ioctl+0x64
#7  sys_ioctl+0x2f6
#8  syscall+0x389
#9  Xsyscall+0x128
lock order "&newfdp->fd_fd.fd_lock"(rwlock) -> "&prime_fpriv->lock"(rwlock) first seen at:
#0  witness_checkorder+0x449
#1  rw_enter_write+0x43
#2  drm_gem_object_release_handle+0x5e
#3  idr_for_each+0xee
#4  drm_gem_release+0x1f
#5  drmclose+0x144
#6  spec_close+0x213
#7  VOP_CLOSE+0x49
#8  vn_closefile+0x9b
#9  fdrop+0x8b
#10 closef+0xaf
#11 fdfree+0xd4
#12 exit1+0x1cf
#13 sys_exit+0x16
#14 syscall+0x389
#15 Xsyscall+0x128


OK mpi@
bob-beck pushed a commit that referenced this pull request Feb 11, 2022
…N9Z)

WITNESS builds broke^W^Wkernels panic on boot as reported by anton and bluhm.
Booting bsd.mp in single-user mode inside VMM shows:

root on sd0a (5f9e458ed30b39ab.a) swap on sd0b dump on sd0b
Enter pathname of shell or RETURN for sh:
witness: lock order reversal:
 1st 0xfffffd801f8ce468 vmmaplk (&map->lock)
 2nd 0xfffffd801b8162c0 inode (&ip->i_lock)
lock order "&ip->i_lock"(rrwlock) -> "&map->lock"(rwlock) first seen at:
#0  rw_enter_read+0x38
#1  uvmfault_lookup+0x8a
#2  uvm_fault_check+0x32
#3  uvm_fault+0xfb
#4  kpageflttrap+0x12c
#5  kerntrap+0x91
#6  alltraps_kern_meltdown+0x7b
#7  copyout+0x53
#8  ffs_read+0x1f6
#9  VOP_READ+0x41
#10 vn_rdwr+0xa1
#11 vmcmd_map_readvn+0xa0
#12 exec_process_vmcmds+0x88
#13 sys_execve+0x732
#14 start_init+0x26f
#15 proc_trampoline+0x1c
lock order data w1 -> w2 missing
# exit
kernel: protection fault trap, code=0
Stopped at      witness_checkorder+0x312:       movl    0x10(%r14),%ecx

gkoehler reported faults on poisened addresses on macppc dual G5.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant