如何使用MDB调试分析Solaris内核死锁的问题

MDB分析Solaris内核死锁问题：一个实例
本文通过一个实例，描述了如何使用MDB调试分析Solaris内核死锁的问题。

死锁是多线程内核必须面对的问题。部分死锁可以通过精心设计来避免。但随着现在操作系统的复杂性和并发性不断增加，代码规模迅速膨胀， 我们难以避免引入一些具有潜在危险的代码。下面的例子就是我们在Solaris系统测试中，遇到的一个读写死锁导致的系统挂起，下面引用的代码都来自 www.opensolaris.org。

内核提供的同步机制都可能导致死锁，比如互斥锁（mutex)， 读写锁（rw lock)等。而我们这个例子遇到是读写锁引起的死锁。

这个问题发生在x64平台系统测试过程中，当我们启动重负载网络背景流量(TCP/UDP)，同时对一个网络聚合（aggregation）进 行反复的管理操作，用dladm，最终导致系统挂起并停止报文的收发。因为可以复现，我们重新启动系统，并在启动时加载了kmdb，当挂起再次发生，我们 有了core dump。

下面我们就通过分析这个core dump，来看看如何用MDB发现死锁的。

首先加载core dump映像，
<SUT> mdb 0

前面提到了，我们在运行网络管理命令的过程中导致了死锁，所以我们知道挂起可能与网络聚合的管理命令dladm有关，看一下dladm在做什 么：
> ::ps ! grep dladm
R 12476 12268 12268   725     0 0x42004000 fffffe87705e23d0 dladm

> fffffe87705e23d0::ps -t
S   PID   PPID   PGID   SID   UID     FLAGS         ADDR NAME
R 12476 12268 12268   725     0 0x42004000 fffffe87705e23d0 dladm
    T 0xffffffffa69be740 <TS_SLEEP>

dladm只有一个线程0xffffffffa69be740，它在休眠。看来很有希望，我们再来看看它为什么休眠，
> 0xffffffffa69be740::findstack -v
stack pointer for thread ffffffffa69be740: fffffe8000a2e570
[ fffffe8000a2e570 _resume_from_idle+0xf8() ]
fffffe8000a2e5b0 swtch+0x185()
fffffe8000a2e650 turnstile_block+0x80d(0， 0， ffffffff93785580，
fffffffffbc039d8， 0， 0)
fffffe8000a2e6b0 rw_enter_sleep+0x186(ffffffff93785580， 0)
fffffe8000a2e6f0 mac_rx_remove+0x32(ffffffff93785310， fffffe86d2d1e368)
fffffe8000a2e720 aggr_port_delete+0x3d(ffffffff8614ccb0)
fffffe8000a2e780 aggr_grp_rem_port+0x1e4(ffffffff85798720， ffffffff8614ccb0，
fffffe8000a2e7e4)
fffffe8000a2e800 aggr_grp_rem_ports+0x182(1， 1， ffffffff9d1faeb8)
fffffe8000a2e840 aggr_ioc_remove+0xc5(ffffffffa27164c0， 100000)
fffffe8000a2e890 aggr_ioctl+0x9b(fffffe8692c06108， ffffffffa27164c0)
fffffe8000a2e8b0 aggr_wput+0x2e(fffffe8692c06108， ffffffffa27164c0)
fffffe8000a2e920 putnext+0x246(fffffe80caeb3658， ffffffffa27164c0)
fffffe8000a2e9f0 strdoioctl+0x3bb(fffffe8692bfee68， fffffe8000a2ea68， 100003，
1， ffffffff9ec93f40， fffffe8000a2ee9c)
fffffe8000a2ed20 strioctl+0x3a73(ffffffff94512e80， 5308， 8037490， 100003， 1，
ffffffff9ec93f40， fffffe8000a2ee9c)
fffffe8000a2ed70 spec_ioctl+0x83(ffffffff94512e80， 5308， 8037490， 100003，
ffffffff9ec93f40， fffffe8000a2ee9c)
fffffe8000a2edc0 fop_ioctl+0x36(ffffffff94512e80， 5308， 8037490， 100003，
ffffffff9ec93f40， fffffe8000a2ee9c)

调用栈输出最左边一列是每个函数栈框的指针，如果函数的参数列表没有解析出来，可以通过栈框指针来帮助你找到传递给函数的参数。但我们这里可以直接得到参 数，我们继续看。

看来这个线程睡眠在一个读写锁0xffffffff93785580上面，那这个锁是什么状态呢？
> ffffffff93785580::rwlock
        ADDR     OWNER/COUNT FLAGS       WAITERS
ffffffff93785580     READERS=1 B011 ffffffffa69be740 (W)
                        ||
          WRITE_WANTED -------+|
            HAS_WAITERS --------+
>
为了好好解释一下上面的MDB输出，我们先看一下这个锁的裸数据是什么样子。
> 0xffffffff93785580/J
0xffffffff93785580:         b

它是0x0B，二进制是1011，对应上面的OWNER/COUNT和FLAGS域。bit0是"wait"， 这里是1，对应"HAS_WAITERS"，表示有线程在等待这个锁。bit1是"wrwant"， 也是1，对应"WRITE_WANTED"，表示至少有一个线程在等待获得写锁，这个线程在这里是0xffffffffa69be740，对应 "WAITERS"。bit2是"wrlock"， 它是决定剩下高位意义的关键参数，这里是0，高位表示这个锁读者的个数，现在是1，就是线程0xffffffffa69be740。如果bit2被设置为 0， 那么高位对应的是现在持有此写锁的线程地址。

到现在，还不知道是哪个线程持有这个读锁，我们要在内核里面查找这个读写锁的地址，看它出现在哪些线程的堆栈中，用kgrep来查一下：

> ffffffff93785580::kgrep | ::whatis
fffffe8000359b28 is in thread fffffe8000359c80’s stack
fffffe8000a2e5d8 is in thread ffffffffa69be740’s stack
fffffe8000a2e638 is in thread ffffffffa69be740’s stack
fffffe8000a2e670 is in thread ffffffffa69be740’s stack
fffffe8000a2e6a8 is in thread ffffffffa69be740’s stack
ffffffffa2f3ce48 is ffffffffa2f3ce38+10， bufctl ffffffffa2f5b478 allocated from
turnstile_cache
ffffffffa69be7c0 is ffffffffa69be740+80， allocated as a thread structure

从输出可以看到这个锁出现在两个线程的堆栈，分别是0xfffffe8000359c80和0xffffffffa69be740。我们已经知道 0xffffffffa69be740对应dladm，但0xfffffe8000359c80是什么？看一下它的调用栈：

> fffffe8000359c80::findstack -v
stack pointer for thread fffffe8000359c80: fffffe80003592b0
[ fffffe80003592b0 resume_from_intr+0xbb() ]
fffffe80003592f0 swtch+0xad()
fffffe8000359390 turnstile_block+0x80d(0， 1， ffffffff85798720，
fffffffffbc039d8， 0， 0)
fffffe80003593f0 rw_enter_sleep+0x1fb(ffffffff85798720， 1)
fffffe8000359430 aggr_m_tx+0x2d(ffffffff85798720， ffffffff98778be0)
fffffe8000359450 dls_tx+0x20(ffffffff9540ca88， ffffffff98778be0)
fffffe8000359480 str_mdata_fastpath_put+0x2c(ffffffff85be6338，
ffffffff98778be0)
fffffe8000359520 tcp_send_data+0x6d7(fffffe80caedbf80， ffffffffa12eb0f8，
ffffffff98778be0)
fffffe8000359600 tcp_send+0x87b(ffffffffa12eb0f8， fffffe80caedbf80， 5b4， 28，
14， 0， fffffe80003596ac， fffffe80003596b0， fffffe80003596b4， fffffe8000359678
， 4fe574， 7fffffff)
fffffe80003596d0 tcp_wput_data+0x6db(fffffe80caedbf80， 0， 0)
fffffe8000359820 tcp_rput_data+0x2dbc(fffffe80caedbd80， ffffffffa0ecd8c0，
ffffffff843def40)
fffffe80003598b0 squeue_drain+0x212(ffffffff843def40， 4， 2fc20433e599)
fffffe8000359930 squeue_enter_chain+0x3bb(ffffffff843def40， ffffffffa66b4f60，
ffffffff98ede720， 10， 1)
fffffe8000359a00 ip_input+0x780(ffffffff85fadae8， fffffe8692bf3088，
ffffffffa66b4f60， e)
fffffe8000359ab0 i_dls_link_ether_rx+0x1ae(ffffffff93784290， fffffe8692bf3088
， ffffffffa66b4f60)
fffffe8000359b00 mac_rx+0x7a(ffffffff85798750， fffffe8692bf3088，
ffffffffa66b4f60)
fffffe8000359b70 aggr_recv_cb+0x1b9(ffffffff8614ccb0， fffffe8692bf3088，
ffffffffa66b4f60)
fffffe8000359bc0 mac_rx+0x7a(ffffffffa2112e00， fffffe8692bf3088，
ffffffffa66b4f60)
fffffe8000359c00 e1000g_intr+0xd2(fffffe813c11f000)
fffffe8000359c60 av_dispatch_autovect+0x83(19)
fffffe8000359c70 intr_thread+0x50()
>
这是一个网卡收包产生的中断，睡眠在另外的一个读写锁0xffffffff85798720上面。我们看一下这个读写锁，

> ffffffff85798720::rwlock
        ADDR     OWNER/COUNT FLAGS       WAITERS
ffffffff85798720 ffffffffa69be740 B101 fffffe8000359c80 (R)
                        | | fffffe800016dc80 (R)
          WRITE_LOCKED ------+ |
            HAS_WAITERS --------+

参照前面描述的读写锁的数据结构意义，我们可以知道这是个写锁，现在被线程0xffffffffa69be740(也就是dladm）所持有。

总结上面的分析我们知道，看到的死锁是这样的：

为了方便，这里我们把0xffffffff85798720叫lock A。另外一个锁叫lock B， 即0xffffffff93785580。网卡线程叫thread A， dladm线程叫thread B。
lock B的持有者是thread A， 当前持有方式是读；等待者是thread B，它试图以写方式获得此锁。Thread B阻塞。
lock A的持有者是thread B， 当前持有方式是写；有两个等待者，我们关心的是thread A，另外一个和这个问题没有关系。Thread A阻塞。

两个线程在互相等待对方释放自己需要的资源，典型的死锁条件导致了最终结果的发生。

我们最后结合Opensolaris的代码来看一下这个死锁的操作时序，本例子和Solaris的aggregation有关，有关 aggregation的背景知识，请参见dladm(1M)的manpage。
/* 因为opensolaris代码会一直发展，以下代码参照2006年9月20日的http: //cvs.opensolaris.org/source/xref/on/，仅供参考*/

1. 当一个TCP报文到达网卡并触发一个中断，下面的调用序列会发生，请参看代码，以e1000g为例：
  e1000g_intr -> mac_rx -> (a serie of TCP rx/tx funcs) -> aggr_m_tx
  上面的调用序列导致下面的锁请求顺序，
  (1) mac_rx -> mi_rx_lock (as RW_READER) mac.c， LINE 1353
  (2) aggr_m_tx -> lg_lock (as RW_READER) aggr_send.c， LINE 220

/* See below code */
http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/io/mac/mac.c ，
  1344 void
  1345 mac_rx(mac_handle_t mh， mac_resource_handle_t mrh， mblk_t *bp)
  1346 {
  1347       mac_impl_t     *mip = (mac_impl_t *)mh;
  1348       mac_rx_fn_t   *mrfp;
  1349
  1350       /*
  1351       * Call all registered receive functions.
  1352       */
  1353       rw_enter(&mip->mi_rx_lock， RW_READER);
  1354       mrfp = mip->mi_mrfp;
  1355       if (mrfp == NULL) {
  1356           /* There are no registered receive functions. */
  1357           freemsgchain(bp);
  1358           rw_exit(&mip->mi_rx_lock);
  1359           return;
  1360       }
  1361       do {
  1362           mblk_t *recv_bp;
  1363
  1364           if (mrfp->mrf_nextp != NULL) {
  1365                 /* XXX Do we bump a counter if copymsgchain() fails? */
  1366                 recv_bp = copymsgchain(bp);
  1367           } else {
  1368                 recv_bp = bp;
  1369           }
  1370           if (recv_bp != NULL)
  1371                 mrfp->mrf_fn(mrfp->mrf_arg， mrh， recv_bp);
  1372           mrfp = mrfp->mrf_nextp;
  1373       } while (mrfp != NULL);
  1374       rw_exit(&mip->mi_rx_lock);
  1375 }
  1376
当报文到达网络接口，中断处理函数会调到mac_rx。在1353行，mip->mi_rx_lock被作为RW_READER持有。

在aggr的代码中， http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/io/aggr/aggr_send.c. In LINE 220， it tries to acquire grp->lg_lock as RW_READER.
  208 /*
  209 * Send function invoked by the MAC service module.
  210 */
  211 mblk_t *
  212 aggr_m_tx(void *arg， mblk_t *mp)
  213 {
  214       aggr_grp_t *grp = arg;
  215       aggr_port_t *port;
  216       mblk_t *nextp;
  217       const mac_txinfo_t *mtp;
  218
  219       for (;;) {
  220           rw_enter(&grp->lg_lock， RW_READER);
  221           if (grp->lg_ntx_ports == 0) {
  222                 /*
  223                 * We could have returned from aggr_m_start() before
  224                 * the ports were actually attached. Drop the chain.
  225                 */
  226                 rw_exit(&grp->lg_lock);
  227                 freemsgchain(mp);
  228                 return (NULL);
  229           }
  230           nextp = mp->b_next;
  231           mp->b_next = NULL;
  232
  233           port = grp->lg_tx_ports[aggr_send_port(grp， mp)];
  234           ASSERT(port->lp_state == AGGR_PORT_STATE_ATTACHED);
  235
  236           rw_exit(&grp->lg_lock);
  237
  238           /*
  239             * We store the transmit info pointer locally in case it
  240             * changes between loading mt_fn and mt_arg.
  241             */
  242           mtp = port->lp_txinfo;
  243           if ((mp = mtp->mt_fn(mtp->mt_arg， mp)) != NULL) {
  244                 mp->b_next = nextp;
  245                 break;
  246           }
  247
  248           if ((mp = nextp) == NULL)
  249                 break;
  250       }
  251       return (mp);
  252 }

2. 此时，当管理员用dladm命令试图从当前聚合(aggregation)中移除一个网络接口(dladm remove-aggr)，下面的调用序列会发生：
aggr_ioctl -> aggr_ioc_remove -> aggr_grp_rem_ports -> aggr_grp_rem_port -> aggr_port_delete -> mac_rx_remove
这里同样会获取mi_rx_lock和lg_lock两个锁，如下所示：

(1) aggr_grp_rem_ports -> "lg_lock" (RW_WRITER)， aggr_grp.c LINE 933
(2) mac_rx_remove -> "mi_rx_lock" (RW_WRITER)， mac.c LINE 925

/* See below code */
http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/io/aggr/aggr_grp.c，
  920 /*
  921 * Remove one or more ports from an existing link aggregation group.
  922 */
  923 int
  924 aggr_grp_rem_ports(uint32_t key， uint_t nports， laioc_port_t *ports)
  925 {
  926       int rc = 0， i;
  927       aggr_grp_t *grp = NULL;
  928       aggr_port_t *port;
  929       boolean_t mac_addr_update = B_FALSE， mac_addr_changed;
  930       boolean_t link_state_update = B_FALSE， link_state_changed;
  931
  932       /* get group corresponding to key */
  933       rw_enter(&aggr_grp_lock， RW_READER);
  934       if (mod_hash_find(aggr_grp_hash， GRP_HASH_KEY(key)，
  935         (mod_hash_val_t *)&grp) != 0) {
  936           rw_exit(&aggr_grp_lock);
  937           return (ENOENT);
  938       }
  939       AGGR_GRP_REFHOLD(grp);
  940       rw_exit(&aggr_grp_lock);
  941
  942       AGGR_LACP_LOCK(grp);
  943       rw_enter(&grp->lg_lock， RW_WRITER);
  944
  945       /* we need to keep at least one port per group */
  946       if (nports >= grp->lg_nports) {
  947           rc = EINVAL;
  948           goto bail;
  949       }
  950
  951       /* first verify that all the groups are valid */
  952       for (i = 0; i < nports; i++) {
  953           if (aggr_grp_port_lookup(grp， ports.lp_devname) == NULL) {
  954                 /* port not found */
  955                 rc = ENOENT;
  956                 goto bail;
  957           }
  958       }
  959
  960       /* remove the specified ports from group */
  961       for (i = 0; i < nports && !grp->lg_closing; i++) {
  962           /* lookup port */
  963           port = aggr_grp_port_lookup(grp， ports.lp_devname);
  964           ASSERT(port != NULL);
  965
  966           /* stop port if group has already been started */
  967           if (grp->lg_started) {
  968                 rw_enter(&port->lp_lock， RW_WRITER);
  969                 aggr_port_stop(port);
  970                 rw_exit(&port->lp_lock);
  971           }
  972
  973           /* remove port from group */
  974           rc = aggr_grp_rem_port(grp， port， &mac_addr_changed，
  975               &link_state_changed);
  976           ASSERT(rc == 0);
  977           mac_addr_update = mac_addr_update || mac_addr_changed;
  978           link_state_update = link_state_update || link_state_changed;
  979       }
  980
  981 bail:
  982       rw_exit(&grp->lg_lock);
  983       AGGR_LACP_UNLOCK(grp);
  984       if (!grp->lg_closing) {
  985           if (mac_addr_update)
  986                 mac_unicst_update(grp->lg_mh， grp->lg_addr);
  987           if (link_state_update)
  988                 mac_link_update(grp->lg_mh， grp->lg_link_state);
  989           if (rc == 0)
  990                 mac_resource_update(grp->lg_mh);
  991       }
  992       AGGR_GRP_REFRELE(grp);
  993
  994       return (rc);
  995 }


http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/io/mac/mac.c，
  910 /*
  911 * Unregister a receive function for this mac. This removes the function
  912 * from the list of receive functions for this mac.
  913 */
  914 void
  915 mac_rx_remove(mac_handle_t mh， mac_rx_handle_t mrh)
  916 {
  917       mac_impl_t         *mip = (mac_impl_t *)mh;
  918       mac_rx_fn_t         *mrfp = (mac_rx_fn_t *)mrh;
  919       mac_rx_fn_t         **pp;
  920       mac_rx_fn_t         *p;
  921
  922       /*
  923       * Search the ’rx’ callback list for the function closure.
  924       */
  925       rw_enter(&(mip->mi_rx_lock)， RW_WRITER);
  926       for (pp = &(mip->mi_mrfp); (p = *pp) != NULL; pp = &(p->mrf_nextp)) {
  927           if (p == mrfp)
  928                 break;
  929       }
  930       ASSERT(p != NULL);
  931
  932       /* Remove it from the list. */
  933       *pp = p->mrf_nextp;
  934       kmem_free(mrfp， sizeof (mac_rx_fn_t));
  935       rw_exit(&(mip->mi_rx_lock));
  936 }
3.     结合代码，我们更容易看出死锁的时序，如下面描述：
(1) 线程B， dladm调用aggr_grp_rem_ports并成功获得lg_lock，以RW_WRITER的写方式
(2) 线程A， TCP报文到达聚合，网卡中断处理程序调用序列调用mac_rx，成功获得mi_rx_lock，以RW_READER方式
(3) 线程A， TCP处理完毕需要返回ACK报文，mac_rx继续调用aggr_m_tx并试图获得lg_lock作为RW_READER， 但是现在lg_lock正在被线程B在步骤(1)以RW_WRITER所持有，所以线程A阻塞
(4) 线程B，继续执行。aggr_grp_rem_ports调用mac_rx_remove并试图获得mi_rx_lock，以RW_WRITER方式， 但现在mi_rx_lock正在被线程A以RW_READER方式持有， 所以线程B也阻塞在这里
(5) 死锁发生