Locking

今天尝试了一下触发zonelim的方法，不过zonelim没搞出来，却发现了另一个问题——如果并发执行ifconfig配置同一块网卡，似乎有由于欠锁导致的断言失败。打算找时间研究一下。

You can obtain latest list from sys/sys/proc.h:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

 * Below is a key of locks used to protect each member of struct proc.  The
 * lock is indicated by a reference to a specific character in parens in the
 * associated comment.
 *      * - not yet protected
 *      a - only touched by curproc or parent during fork/wait
 *      b - created at fork, never changes
 *              (exception aiods switch vmspaces, but they are also
 *              marked 'P_SYSTEM' so hopefully it will be left alone)
 *      c - locked by proc mtx
 *      d - locked by allproc_lock lock
 *      e - locked by proctree_lock lock
 *      f - session mtx
 *      g - process group mtx       
 *      h - callout_lock mtx
 *      i - by curproc or the master session mtx
 *      j - locked by sched_lock mtx
 *      k - only accessed by curthread
 *      l - the attaching proc or attaching proc parent
 *      m - Giant
 *      n - not locked, lazy
 *      o - ktrace lock
 *      p - select lock (sellock)
 *      q - td_contested lock
 *      r - p_peers lock
 *      x - created at fork, only changes during single threading in exec
 *      z - zombie threads/ksegroup lock

I have enabled PREEMPTION, FULL_PREEMPTION with ULE. Now I get strange result here:

• propagate_priority gets a TD_ON_LOCK(td)
• It tries to panic(), unfortunatelly, ts->ts_lockobj here is NULL
• A fatal trap 12 happens.

It seems that ts->ts_lockobj was touched by sched_lend_prio, for unknown reasons. Maybe there is some lock releases?

What’are LORs? To quote Robert Watson:

“These warnings are generated by Witness, a run-time lock diagnostic system found in FreeBSD 5-CURRENT kernels (but removed in releases). You can read more about Witness in the WITNESS(4) man page, which talks about its capabilities. Among other things, Witness performs run-time lock order verification using a combination of hard coded lock orders, and run-time detected lock orders, and generates console warnings when lock orders are violated. The intent of this is to detect the potential for deadlocks due to lock order violations; it’s worth observing that Witness is actually slightly conservative, and so it’s possible to get false positives. In the event that Witness is accurately reporting a lock order problem, it’s basically saying “If you were unlucky, a deadlock would have happened here”. There are a couple of “well known” false positives, which we need to do a better job of documenting to prevent spurious reports. The non-well-known ones typically correspond to bugs in newly added locking, as lock order reversals usually get fixed pretty quickly because Witness is busy generating warnings :-).”

The SMP case seems to have something wrong with it. My MARCH=p4 and -O optimized kernel often crashes when shutting down on beastieng.frontfree.net. Apparantly this is lock related (we can see the panic strings there not to be outputing atomically, and they just mixed with each other).