kern/175705: "panic: process not held" when invoking userland dtrace with INVARIANTS enabled

[Alan Somers]

>Number:         175705
>Category:       kern
>Synopsis:       "panic: process not held" when invoking userland dtrace with INVARIANTS enabled
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jan 30 17:00:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator:     Alan Somers
>Release:        9.1
>Organization:
Spectralogic
>Environment:
FreeBSD testy 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #2: Thu Jan 24 19:34:34 MST 2013     root@****:/tb/3a9569b9/tinderbuild/jails/9/obj/net/nexus/scratch/cruise/projects/Strata-debug/SpectraBSD/sys/STRATA_DBG  amd64

>Description:
I tried using userland dtrace exactly according to the instructions at https://wiki.freebsd.org/DTrace/userland.  The following panic resulted:

panic: process not held
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at 0xffffffff8036266a = db_trace_self_wrapper+0x2a
kdb_backtrace() at 0xffffffff8090c4b7 = kdb_backtrace+0x37
panic() at 0xffffffff808d4a48 = panic+0x1d8
proc_ops() at 0xffffffff8232a03a = proc_ops+0x8a
fasttrap_pid_probe() at 0xffffffff8232b319 = fasttrap_pid_probe+0x9a9
trap() at 0xffffffff80bd2e85 = trap+0x2c5
calltrap() at 0xffffffff80bbcec3 = calltrap+0x8
--- trap 0x3, rip = 0x80086a911, rsp = 0x7fffffffdb98, rbp = 0x7fffffffdba0 ---
KDB: enter: panic
[ thread pid 40555 tid 114882 ]
Stopped at      0xffffffff8090c17b = kdb_enter+0x3b:    movq    $0,0xb4d1a2(%rip)


Looking at the source, it seems that fasttrap_isa.c acquires a process lock at line 1036, drops it at line 1184, then calls uwrite at line 1737.  uwrite calls proc_ops() which panics because it expects a process lock to be held.  The subversion history shows that this bug was introduced in change 227291, which replaced fasttrap_copyout (which does not require a process lock) with uwrite (which does).  It probably wasn't caught at the time because nobody tested it with INVARIANTS.
>How-To-Repeat:
1) Load a kernel with INVARIANTS enabled. 
2) kldload dtraceall
3) Try to dtrace a user process according to the instructions at https://wiki.freebsd.org/DTrace/userland
>Fix:
Possibly could be fixed be reacquiring the process lock before calling uwrite().

>Release-Note:
>Audit-Trail:
>Unformatted: