FreeBSD

Now I got (partially) the point:

• A newly fork’ed thread grabs Giant
• Subsequently, the mutex procedure will call turnstile_wait
• However, the td->td_sched->ke_runq is NULL (means that some part of the new thread is not initialized completely)
• So boom! panic.

Interestingly this does not happen in !PREEMPTION case.

Now my question are:

1. who forks?
2. is it the child? the parent?
3. why the initialization is not completed with a wrong result?

I have done several experiments/asserts to ensure that the panic is related to ULE+PREEMPTION case only.

ULE: no panic
4BSD: no panic
4BSD+PREEMPTION: no panic

My latest progress is that I found that sched_switch in ULE for the threaded case, can decide whether subsequent call would panic. Investigating.

My company has offered me some test equipment (namely, a HP 360 with ILO, which is *great* for debugging at home!), and I has started to trip over the ULE code and find for bugs.

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

Today Giorgos Keramidas (keramida@) has noted that the following skill that can minimize lock period:

1. save the commit message to a file (say ~/commitlog)
2. cvs ci -F ~/commitlog file[…]

It seems that I have hit a bug, where kseq_nice_rem is being called too much. Have read the code and added some KASSERT/MPASS’es.

pav@ has put together this which looks quite interesting. Have a read of it :-)

(Got that from arved@’s blog)

Murray老大在FreeBSD.org发的一则消息，说……Eric Raymond在巴西举行的FISL (Fórum Internacional de Software Livre，国际软件发布论坛)中提到，“Basically, we don’t need GPL. It’s based on the belief that open source software is weak and needs to be protected. With it, we continue injuring ourselves, cutting ourselves from the economic benefits of BSD license”(基本上，我们并不需要GPL。它是基于认为开源软件非常弱小因而需要保护而产生的。由于它(GPL)，我们在不断伤害我们自己，并将我们与BSD授权在经济上的优点割裂开来)。

所以我今天一鼓作气搞到了5.9。还有8个section，余下的loader估计基本上会搞定。

现在可以通过 这里 访问最新的快照。如果有问题记得跟我联系。

Today quakelee@ has reported that an(4) is broken with a recent -CURRENT. I have identified that that was related to our recent ifnet change and has fixed it under scottl@’s approval.