diff options
| author |   art <art@openbsd.org> | 2011-07-06 01:49:42 +0000 |
|---|---|---|
| committer | art <art@openbsd.org> | 2011-07-06 01:49:42 +0000 |
| commit | e57a349ae46b9021a958191d02da8e8937794887 (patch) | |
| tree | 82d598959ebdf6b862e8286835ed9de692f93da2 /sys/kern/kern_lock.c | |
| parent | Oops. I did an oga. Put back important line (set b_bcount) I didn't mean to delete. (diff) | |
| download | wireguard-openbsd-e57a349ae46b9021a958191d02da8e8937794887.tar.xz wireguard-openbsd-e57a349ae46b9021a958191d02da8e8937794887.zip | |
Stop using the P_BIGLOCK flag to figure out when we should release the
biglock in mi_switch and just check if we're holding the biglock.
The idea is that the first entry point into the kernel uses KERNEL_PROC_LOCK
and recursive calls use KERNEL_LOCK. This assumption is violated in at
least one place and has been causing confusion for lots of people.
Initial bug report and analysis from Pedro.
kettenis@ beck@ oga@ thib@ dlg@ ok
Diffstat (limited to 'sys/kern/kern_lock.c')
| -rw-r--r-- | sys/kern/kern_lock.c | 4 |
1 files changed, 1 insertions, 3 deletions
diff --git a/sys/kern/kern_lock.c b/sys/kern/kern_lock.c index 2e4bd1f8ac7..bdc4f1129cd 100644 --- a/sys/kern/kern_lock.c +++ b/sys/kern/kern_lock.c @@ -1,4 +1,4 @@ -/* $OpenBSD: kern_lock.c,v 1.35 2010/04/26 05:48:17 deraadt Exp $ */ +/* $OpenBSD: kern_lock.c,v 1.36 2011/07/06 01:49:42 art Exp $ */ /* * Copyright (c) 1995 @@ -378,13 +378,11 @@ _kernel_proc_lock(struct proc *p) { SCHED_ASSERT_UNLOCKED(); __mp_lock(&kernel_lock); - atomic_setbits_int(&p->p_flag, P_BIGLOCK); } void _kernel_proc_unlock(struct proc *p) { - atomic_clearbits_int(&p->p_flag, P_BIGLOCK); __mp_unlock(&kernel_lock); } |