FreeBSD

没完没了的phpBB漏洞！！再也不能忍下去了！

今天终于找到alu跟他要了www的root，然后开始升级。

首先import新版本。

然后开始合并冲突，phpBB这群家伙居然到了这么多的patchlevel还在改表结构，真不知道他们的大脑是用来想什么的，预想www必然会出问题，果然，不过一切在掌控之中。

Looking forward to it. Only 1 week left to RELENG_6!

Thanks goes to my parents, and yes, today I’m 23 yrs old.

(Believe it or not, FreeBSDChina.org is 3 years old today, too)

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)