http://httpd.apache.org/docs/2.0/misc/perf-tuning.html

另外原来在gentoo里，如果不指定APACHE2_MPMS，但指定了threads USE flag，那么就会启用MPM worker.
http://httpd.apache.org/docs/2.0/mod/worker.html

各位已经知道的不要笑话俺。这个惊天大秘密终于被我发现了，考！

看一看 Documentation/networking/proc_net_tcp.txt

   00000150:00000000 01:00000019 00000000
      |        |     |     |       |--> number of unrecovered RTO timeouts
      |        |     |     |----------> number of jiffies until timer expires
      |        |     |----------------> timer_active (see below)
      |        |----------------------> receive-queue
      |-------------------------------> transmit-queue

这个receive-queue就是：sk->sk_ack_backlog

具体的代码在：http://lxr.linux.no/#linux+v2.6.31/net/ipv4/tcp_ipv4.c#L2236

于是我终于大概明白了为什么我的gentoo-cn.org过一段时间就会连接不上……

且看gentoo-cn.org上现在的80端口的sk_ack_backlog大小：
$ cat /proc/net/tcp | grep 00:0050
   5: 00000000:0050 00000000:0000 0A 00000000:00000081 02:0000000A 00000000     0        0 11883408 2 980000003eb4ad00 300 0 0 2 -1                 

注意粗体部分：0x81，就是129！正好大于128!!!

128是什么？128就是 /proc/sys/net/core/somaxconn, so max connections, 默认的accept q大小！！！

所以内核就会认为acceptq满了！！！http://lxr.linux.no/#linux+v2.6.31/include/net/sock.h#L539

所以后续连接最多只能处于SYN_RECV状态，而永远不会再有连接转成ESTABLISHED状态！！！

不过问题还没最终解决。因为目前我不能理解的是，为什么有129这么高。而且如果说是因为没有accept()，那服务器端也没有CLOSE_WAIT状态的连接。

啊！！！

PS：发现apache配置中MaxClient为150，而目前有150个线程疑似处于死锁状态：
#0  0x2acd4144 in __lll_lock_wait () from /lib/libpthread.so.0
#1  0x2accfbb8 in pthread_cond_destroy@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2  0x2bae081c in my_thread_end () from /usr/lib/libmysqlclient_r.so.15
#3  0x2b5b4808 in zm_deactivate_mysql () from /usr/lib/apache2/modules/libphp5.so
#4  0x2b6f48a8 in module_registry_cleanup () from /usr/lib/apache2/modules/libphp5.so
#5  0x2b6ffedc in zend_hash_reverse_apply () from /usr/lib/apache2/modules/libphp5.so
#6  0x2b6f1e60 in zend_deactivate_modules () from /usr/lib/apache2/modules/libphp5.so
#7  0x2b693d00 in php_request_shutdown () from /usr/lib/apache2/modules/libphp5.so
#8  0x2b78aa84 in ?? () from /usr/lib/apache2/modules/libphp5.so

案情渐渐明朗……

PPS: 果然，杀掉其中一个进程（含27个线程，其中有25个死锁），就可以访问了。
我猜测apache在select()返回后，先创建线程，然后在线程中accept()。
但是现在线程总数的限制已经达到。所以无法创建新线程来accept()。
同时由于某目前尚未了解到的原因，原来的ESTABLISHED状态的连接也没了。

为解决这个问题，眼下之计，要加入debug信息重新emerge apache。
好在我有debugemerge脚本，哼哼。
然后在下次问题再重现时，再分析为何死锁。
不能学hw，明明缺少信息，还白耗时间在上面，硬要找出原因。

和其他工作仅出卖上班时间不同，这份工作是要随时准备好出卖任何一段时间段的时间。
除非你确实因故不能打开手机。
比如在飞机上……

http://lwn.net/Articles/355416/

最近的Real Time Linux Workshop上有个讨论，有关开发者和学术界的关系。中间提到如何鼓励学生参与社区的开发。但同时提到，如果学生根本就不想参与社区开发，那所有鼓励措施都是没用的。而且：

As strange as it seems, it appears to not be an entirely attractive profession. It takes years of work to become a competent engineer; many are simply unwilling to put in that time. Whether things have gotten worse because people expect instant gratification now, or whether it has always been this way was a matter of debate. One panelist suggested that things will only get better when good engineers make more money than good lawyers.

终于见过了大爷。
拍的不错，应该再继续拍。
把后边几年的事都拍拍。
http://zh.wikipedia.org/wiki/%E7%BD%97%E9%9A%86%E5%9F%BA

10号回来。

一件未完成，一件基本完成。

基本完成的是升级ps3上的gentoo的内核到2.6.30。
不过发现有个bug，现在git clone ps3的git tree，看看是否还有。还有的话，我的内核补丁又要多一个了。

未完成的是一个诡异的2f盒子上的bug。
如果单启动X，然后再起一个firefox/pidgin，X就会死掉。再起xterm没事。
本来以为是X的补丁的问题。
后来发现startx没事。
后来发现死的原因是X的main里的无限循环里一个循环结束了，又开始了一个新的循环。
又一次执行了InitOutput，这里面最终会再次映射sysfs里显卡的resource文件到X的地址空间。
但实际上已经映射过了，libpciaccess在这种情况下会返回错误EINVAL。
因为我对X的工作机制还不完全了解，所以目前无法断定问题在哪里。
现在先记录一下，有空再来看。

明天要上班，调休。
国庆放11天假，但有两天是“强制”放掉的年假，囧……
中国特色……

不让它交换出去。Linux上的答案是ramfs。http://wiki.debian.org/ramfs

但此刻我却像hw的r&d

今天！
今天是一个繁忙的日子！
首先是准备演讲稿。
然后华为找我问问题。
然后去找莫老师吃饭，但是因为华为的事情耽误了，我到了吃饭的地方已经吃完了。
然后wjj载我去深大参加自由软件日活动。
jx和莫老师同行，在深大照了像。然后莫老师就去赶飞机了。
真是不好意思，老人家好不容易来一趟，我却没赶上跟老头子吃顿饭。

然后就是自由软件日活动。
原来这次活动主要是Sun赞助的。
深大的java学会搞的。Szlug协助。

4个演讲：
1. JavaFX
2. 原计划是gentoo，临时改成一个讲根据哼唱搜索歌曲的（主讲人非我，其实本来我很期待的，因为有别人肯讲gentoo，说不定真有世外高人）
3. AlacrityVM http://groups.google.com/group/szlug/msg/9a7881a931f183ea
4. iRedMail http://groups.google.com/group/szlug/browse_thread/thread/e5cb65b4c62cb541

不是自买自夸，不过后两个才真正像自由软件日上应该出现的演讲。
前面两个几乎没有互动。后两个讲者和观众的互动很多，特别是张煌彬的演讲。
我们两个都在讲述技术之外，穿插了一些自由软件的相关名词，自由软件社区的价值取向，行事方法的介绍。
相信对于不甚熟悉此道的听众来说，还是有些启发意义的。
这才是自由软件日应该起到的作用。

Last but not least，要感谢深大能提供聚会的场地，感谢lug众兄弟的捧场，感谢sun的赞助，嘿嘿

说明：这是我自用的，顺便供大家参考（如果有需要的话）。
请不要照搬，除非你了解里面每个选项的意义。否则出了事情，我不负任何责任，:)

首批加入的有screenrc和vimrc。
我发现在华为，没有这两个东西，我的效率大减。

http://www.gentoo-cn.org/gitweb/?p=rconf.git

git clone git://www.gentoo-cn.org/var/git/rconf.git

昨天从美国来的CTO/VP Moiz Kohari那里知道AlacrityVM这么个东西，还是蛮振奋人心的。

http://developer.novell.com/wiki/index.php/AlacrityVM
http://lwn.net/Articles/345296/

KVM和Xen虽然都不是Novell的，但Novell也有自己的东西，:)

但是还是在下班的时间

哎

感谢杨珂提供的帐号！

舜发于畎亩之中，傅说举于版筑之中，胶鬲举于鱼盐之中，管夷吾举于士，孙叔敖举于海，百里奚举于市。 
故天将降大任于是人也，必先苦其心志，劳其筋骨，饿其体肤，空乏其身，行拂乱其所为，所以动心忍性，曾益其所不能。 
人恒过，然后能改；困于心，衡于虑，而后作；征于色，发于声，而后喻。入则无法家拂士，出则国外患者国恒亡。 
然后知生于忧患，而死于安乐也。

我前一两个月太安乐了，明天要开始忧患了……

EDIT：更新了第四条

首先inline在任何gcc版本里应该都是有效的，只是要开优化

其次extern inline并不会导致函数不被inline，只是要开优化

第三extern inline和static inline是有区别的。引用Linus的解释：

    * "static inline" means "we have to have this function, if you use it
         but don't inline it, then make a static version of it in this
         compilation unit"

    * "extern inline" means "I actually _have_ an extern for this function,
         but if you want to inline it, here's the inline-version"

这意味着在使用extern inline的情况下，假如不inline该函数，则必须在其他编译单元里
定义该函数。否则就和函数未定义一样，undefined reference to ...

第四，gcc 4.3之后，应该使用__extern_inline（定义于<sys/cdefs.h>，非编译器关键字，仅适用于userland），否则在-std=c99或者gnu99的情况下，会出现函数多次定义。

参考：
http://zhllg.spaces.live.com/blog/cns!956A48A2D7ED7265!231.entry
http://zhllg.spaces.live.com/blog/cns!956A48A2D7ED7265!2816.entry

http://lwn.net/Articles/349999/
所有的第一手资料都可以在上面的连接里找到。

简单分析一下：
首先，这个漏洞的起源在于部分协议的.sendpage函数指针没有初始化，为0。那么在sendpage系统调用到这个函数指针所指向的函数时，实际上就是跳转到0x0这个地址上去执行放在那里的代码了。只要能把你想执行的代码事先先放在那里，就行了。你想让你的代码做什么事情都可以。但最有吸引力的无疑是利用这段代码赋予当前进程root权限。直接赋予，因为是运行在内核态。这个漏洞利用的实质就是在用户态控制内核态将会执行的代码，这是核心所在。在2.6.23之前（不包括2.0）的内核里，实现起来没有任何险阻。但在2.6.23及其之后的内核上实现起来还要经历一个坎。

因为，就是为了防止此类问题的再次发生，2.6.23以后的内核有一个/proc/sys/vm/mmap_min_addr文件，里面定义了可以mmap的最小地址，默认是4096，也就是说0号页不可以mmap。那就没有办法往里面放东西了。

然而，如果有SELinux的话，在某些条件下，这个mmap_min_addr是不起效的，那样就可以映射0号页。或者如果没有SELinux，可以利用MMAP_PAGE_ZERO personality（这依赖于内核的另一个bug）。这需要一个可以以不exec一个独立程序的形式执行我们指定的代码setuid root程序。pulseaudio正是这样一个选择。具体过程如下：我们设定进程的personality，令其包含MMAP_PAGE_ZERO，然后再exec这个suid程序。因为有MMAP_PAGE_ZERO（bug即在此，suid程序执行前应清除这个personality），同时有root权限，所以需要且可以映射0号页。假如以exec独立程序的形式来执行我们执行代码，那么在映射0号页（因为有MMAP_PAGE_ZERO）的时候，因为root权限已经被丢弃（一般的安全常识，所以suid程序作者都会这样做），所以cap_file_mmap()函数就会失败，无法exec我们的程序。而pulseaudio可以通过-L选项来指定一个共享库来执行，无需exec，且pulseaudio进程本身已经映射了0号页。虽然只是只读，可执行，但我们可以重新映射为可写。

至于0x0处的代码的具体实现，在x86上就是jmp $8, 0x8处放置的就是我们指定的函数的地址。

总结一下这个漏洞利用程序的流程：
1. 假如是2.6.23或以后版本的内核，利用SELinux或者pulseaudio来映射0号页；2.6.23之前的内核直接映射。
2. 在0x0地址上放上我们的可以获取root权限的代码
3. 创建某个可被攻击的Domain的socket，并调用sendpage()（就是调用0x0处的代码）。此步之后即获得root权限。
4. exec /bin/sh

最后的话：
1. 这个漏洞仅仅是本地权限提升，且依赖SELinux和pulseaudio（当然不是只有pulseaudio，但应该很少）
2. SELinux还是有作用，SELinux里连接网络的进程无论如何不可以映射0号页。所以最危险的是没有启用SELinux同时装了pulseaudio的机器。

区区一个中学都有自己的官方博客：
http://www.bj50.com/blog/?p=760

龙芯，没有自己的官方博客……