1.問題現象
ビジネスプロセス（ユーザーモードマルチスレッドプログラム）がハングし、オペレーティングシステムが応答せず、システムログに異常はありません。プロセスのカーネルモードスタックから、すべてのスレッドが次のカーネルモードスタックフローでスタックしているようです。
[root @ vmc116〜] ＃cat / proc / 27007 / task / 11825 / stack
[] retint_careful + 0x14 / 0x32
[ ] 0xffffffffffffffff
2、問題点分析
2.1、カーネルスタック分析
カーネルスタックから、すべてのプロセスがretint_carefulでブロックされます。これは、割り込みリターンプロセスのプロセスです。コード（アセンブリ）は次のとおりです
。entry_64.S：
ret_from_intr:
DISABLE_INTERRUPTS(CLBR_NONE)
TRACE_IRQS_OFF
decl PER_CPU_VAR(irq_count)
/* Restore saved previous stack */
popq %rsi
CFI_DEF_CFA rsi,SS+8-RBP /* reg/off reset after def_cfa_expr */
leaq ARGOFFSET-RBP(%rsi), %rsp
CFI_DEF_CFA_REGISTER rsp
CFI_ADJUST_CFA_OFFSET RBP-ARGOFFSET
...
retint_careful://中断返回
CFI_RESTORE_STATE
bt $TIF_NEED_RESCHED,%edx
jnc retint_signal
TRACE_IRQS_ON
ENABLE_INTERRUPTS(CLBR_NONE)
pushq_cfi %rdi
SCHEDULE_USER//调度点
popq_cfi %rdi
GET_THREAD_INFO(%rcx)
DISABLE_INTERRUPTS(CLBR_NONE)
TRACE_IRQS_OFF
jmp retint_checkこれは実際には、ユーザーモードプロセスがユーザーモードによって中断され、retint_careful + 0x14 / 0x32と組み合わされて分解された後、中断から戻るプロセスです。ブロッキングポイントが実際にSCHEDULE_USERに
あり、実際にスケジュールのためにschedule（）を呼び出していることを確認できます。 、つまり、プロセスが割り込みリターンフローに進むときに、スケジュールする必要があることがわかったため（TIF_NEED_RESCHEDが設定されている）、ここでスケジュールが発生します。
質問があります：スタック内にschedule（）レベルのスタックフレームが表示されないのはなぜですか？
これはアセンブリによって直接呼び出されるため、関連するスタックフレームのプッシュおよびコンテキスト保存操作はありません。
2.2。ステータス情報分析を実行する
topコマンドの結果から、関連するスレッドは実際にはR状態にあり、CPUはほぼ完全に使い果たされており、それらのほとんどはユーザーモードで消費されています。
[root@vmc116 ~]# top
top - 09:42:23 up 16 days, 2:21, 23 users, load average: 84.08, 84.30, 83.62
Tasks: 1037 total, 85 running, 952 sleeping, 0 stopped, 0 zombie
Cpu(s): 97.6%us, 2.2%sy, 0.2%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 32878852k total, 32315464k used, 563388k free, 374152k buffers
Swap: 35110904k total, 38644k used, 35072260k free, 28852536k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
27074 root 20 0 5316m 163m 14m R 10.2 0.5 321:06.17 z_itask_templat
27084 root 20 0 5316m 163m 14m R 10.2 0.5 296:23.37 z_itask_templat
27085 root 20 0 5316m 163m 14m R 10.2 0.5 337:57.26 z_itask_templat
27095 root 20 0 5316m 163m 14m R 10.2 0.5 327:31.93 z_itask_templat
27102 root 20 0 5316m 163m 14m R 10.2 0.5 306:49.44 z_itask_templat
27113 root 20 0 5316m 163m 14m R 10.2 0.5 310:47.41 z_itask_templat
25730 root 20 0 5316m 163m 14m R 10.2 0.5 283:03.37 z_itask_templat
30069 root 20 0 5316m 163m 14m R 10.2 0.5 283:49.67 z_itask_templat
13938 root 20 0 5316m 163m 14m R 10.2 0.5 261:24.46 z_itask_templat
16326 root 20 0 5316m 163m 14m R 10.2 0.5 150:24.53 z_itask_templat
6795 root 20 0 5316m 163m 14m R 10.2 0.5 100:26.77 z_itask_templat
27063 root 20 0 5316m 163m 14m R 9.9 0.5 337:18.77 z_itask_templat
27065 root 20 0 5316m 163m 14m R 9.9 0.5 314:24.17 z_itask_templat
27068 root 20 0 5316m 163m 14m R 9.9 0.5 336:32.78 z_itask_templat
27069 root 20 0 5316m 163m 14m R 9.9 0.5 338:55.08 z_itask_templat
27072 root 20 0 5316m 163m 14m R 9.9 0.5 306:46.08 z_itask_templat
27075 root 20 0 5316m 163m 14m R 9.9 0.5 316:49.51 z_itask_templat
...2.3、プロセススケジューリング情報
関連するスレッドのスケジューリング情報から：
[root @ vmc116〜] ＃cat / proc / 27007 / task / 11825 / schedstat
15681811525768 129628804592612 3557465
[root @ vmc116〜] ＃cat / proc / 27007 / task / 11825 / schedstat
15682016493013 129630684625241 3557509
[root @ vmc116〜] ＃cat / proc / 27007 / task / 11825 / schedstat
15682843570331 129638127548315 3557686
[root @ vmc116〜] ＃cat / proc / 27007 / task / 11825 / schedstat
15683323640217 129642447477861 3557793
[root @ vmc116〜] ＃cat / proc / 27007 / task / 11825 / schedstat
15683698477621 129645817640726 3557875
は、関連するスレッドのスケジューリング統計が増加していることを検出しました。これは、関連するスレッドが実行するようにスケジュールされていることを示し、そのステータスは常にRであり、ユーザーモードで発生する可能性が高いと推測されます。デッドループ（または非スリープデッドロック）。
ここに別の質問があります。通常見られる無限ループプロセスによって引き起こされる100％の占有率ではなく、各スレッドのCPU占有率が上から約10％しかないのはなぜですか。
多くのスレッドがあり、それらの優先順位はすべて同じであるため、CFSスケジューリングアルゴリズムによれば、タイムスライスは均等に分散され、1つのスレッドがCPUを独占することはありません。その結果、複数のスレッドが順番にスケジュールされ、すべてのcpuが消費されます。。
別の質問：この場合、カーネルがソフトロックアップを検出しないのはなぜですか？
ビジネスプロセスの優先度は高くないため、ウォッチドッグカーネルスレッド（最も優先度の高いリアルタイムスレッド）のスケジューリングには影響せず、ソフトロックアップは発生しません。
別の質問：スレッドスタックを表示するたびに、他の場所ではなく、retint_carefulで常にブロックされるのはなぜですか？
これ（割り込みが戻ったとき）がスケジューリングのタイミングであるため、（他の状況に関係なく）他の時点でスケジューリングを行うことはできません。また、プロセススケジューリングにも依存する必要があるスレッドスタックの動作をチェックするため、毎回チェックします。スタックするときは、スタックを監視するプロセス（catコマンド）がスケジュールされ、割り込みが戻るときなので、今見たブロッキングポイントはretint_carefulです。
2.4、ユーザーの態度分析
上記の分析から、ユーザーモードでデッドロックが発生したと推測されます（ここではデッドロックは発生しません。デッドロックが発生した場合、カーネルモードでロックされているプロセスが存在する必要があります）。ミューテックスカーネルスタックは次のとおりです。
Detaching from program: /sbc/wq/some_func/share_mem_mutex, process 29758
[root@localhost ~]# cat /proc/29758/stack
[<ffffffff810a4179>] futex_wait_queue_me+0xb9/0xf0
[<ffffffff810a53a8>] futex_wait+0x1f8/0x390
[<ffffffff810a6c11>] do_futex+0x121/0xb10
[<ffffffff810a767b>] sys_futex+0x7b/0x170
[<ffffffff8100b0d2>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
この時点で、ユーザーモードを使用して方法を確認できます。
デバッグ情報を展開してから、gdbが関連するプロセスをアタッチし、スタックを確認して、コードロジック分析を組み合わせます。
問題は確かにユーザーモードプロセスの無限のループであることが最終的に確認されました。