Presentation title (on one or two lines)

Size: px

Start display at page:

Download "Presentation title (on one or two lines)"

さなえこやぎ
6 years ago
Views:

1 社会インフラシステムへの Linux の適用 Applying Linux to Social Infrastructure Systems ( 株 ) 東芝宮川雅紀 2016 年 3 月 11 日 2016 Toshiba Corporation

2 自己紹介 2016 Toshiba Corporation 2

3 目次システム概要 Linux 適用で発生した問題の事例事例 1 : pthread_mutex_lockによるデッドロック事例 2:e1000ドライバによるkernelパニックまとめ社会インフラシステムへの Linux 適用で見えてきた課題 2016 Toshiba Corporation 3

4 目次システム概要 Linux 適用で発生した問題の事例事例 1 : pthread_mutex_lockによるデッドロック事例 2:e1000ドライバによるkernelパニックまとめ社会インフラシステムへの Linux 適用で見えてきた課題 2016 Toshiba Corporation 4

5 システム概要何故 Linux か? TCP/IPベースの産業用通信プロトコルスタックライブラリが入手しやすい豊富なCPUアーキテクチャサポート商用利用可能なディストリビューション産業用通信プロトコルスタックをサードベンダから購入する弊社で開発したシステムの概要は以下 Main Control Application Communication Control Application ModbusTCP Foundation Fieldbus Profibus DP DeviceNet User Land ( Ex. Debian) Linux Kernel 2016 Toshiba Corporation 5

6 目次システム概要 Linux 適用で発生した問題の事例事例 1 : pthread_mutex_lockによるデッドロック事例 2:e1000ドライバによるkernelパニックまとめ社会インフラシステムへの Linux 適用で見えてきた課題 2016 Toshiba Corporation 6

7 Linux を適用して発生した問題の事例事例 1 pthread_mutex_lockによるデッドロック問題の概要 Linux 適用製品の連続通電にて 1 週間に2,3 回の割合でWDTリセット発生問題発生時あるプロセスのCPU 使用率が90% を超える問題を起こすプロセスのスケジューリングポリシはSCHED_FIFO ( 優先度 98) 2016 Toshiba Corporation 7

8 Linux を適用して発生した問題の事例 proc/<pid>/task/stat からスレッドの状態を得る問題のスレッドより高い優先度を持つスレッド以外スケジュールされない状態 /proc/1649/task # cat */stat ; sleep 20; cat */stat; 1649 (hoge) R < 省略 > 1652 (hoge) R < 省略 > 1654 (hoge) S < 省略 > 1655 (hoge) R < 省略 > 1656 (hoge) R < 省略 > 1657 (hoge) R < 省略 > 1658 (hoge) R < 省略 > 優先度 99のスレッド CPU 使用時間が更新されていない 1659 (hoge) R < 省略 > < 20sec > 優先度 98のスレッド CPU 使用時間が更新されている 1649 (hoge) R < 省略 > 1652 (hoge) R < 省略 > 1654 (hoge) S < 省略 > 1655 (hoge) R < 省略 > 1656 (hoge) R < 省略 > 1657 (hoge) R < 省略 > 1658 (hoge) R < 省略 > 1659 (hoge) R < 省略 > 2016 Toshiba Corporation 8

9 Linux を適用して発生した問題の事例 gdbserver + gdb で問題が発生したプロセスにアタッチ pthread_mutex_lockの呼び出しから戻らないことが判明この時ロック変数は優先度 99のスレッドによってロックされていた怪しいと思った点 pthread inheritanceを使用していない優先度 99のスレッドと優先度 98のスレッドが排他制御を行っている優先度逆転現象が起こり得る! 納得できない点 PTHREAD_MUTEX_INITIALIZERで初期化していない優先度逆転現象が起きたとしてもデッドロックはしないはず常時発生するわけではない 2016 Toshiba Corporation 9

10 Linux を適用して発生した問題の事例問題の発生を ftrace でトレースする短時間で sys_futex を繰り返し呼び出していることが分かる <function-tracer> ~/dbgfs/tracing # cat trace # tracer: function # # TASK-PID CPU# TIMESTAMP FUNCTION # hoge-1657 [000] : futex_wait_setup <-futex_wait hoge-1657 [000] : get_futex_key <-futex_wait_setup hoge-1657 [000] : sys_futex <-syscall_call hoge-1657 [000] : do_futex <-sys_futex hoge-1657 [000] : futex_wait <-do_futex hoge-1657 [000] : futex_wait_setup <-futex_wait hoge-1657 [000] : get_futex_key <-futex_wait_setup hoge-1657 [000] : sys_futex <-syscall_call hoge-1657 [000] : do_futex <-sys_futex hoge-1657 [000] : futex_wait <-do_futex hoge-1657 [000] : futex_wait_setup <-futex_wait hoge-1657 [000] : get_futex_key <-futex_wait_setup 2016 Toshiba Corporation 10

11 Linux を適用して発生した問題の事例 sys_futex の実装を確認するロック変数が 4 バイト境界に配置されていない時 -EINVAL を返す static int get_futex_key(u32 user *uaddr, int fshared, union futex_key *key) { unsigned long address = (unsigned long)uaddr; struct mm_struct *mm = current->mm; struct page *page; int err; /* * The futex address must be "naturally" aligned. */ key->both.offset = address % PAGE_SIZE; if (unlikely((address % sizeof(u32))!= 0)) return -EINVAL; address -= key->both.offset; 一方 pthread_mutex_lockはロック変数がロックされている状態でsys_futexから-einval が返されたとき sys_futexを再度呼び出す実装実際にロック変数のアドレスが 4 バイト境界ではなかった! 2016 Toshiba Corporation 11

12 Linux を適用して発生した問題の事例問題発生時の pthread_mutex_lock の動作まとめ thread A thread B 優先度 99 優先度 98 pthread_mutex_lock クリティカルセクション lock preempt ロック変数 wait thread A スケジュール待ち therad B ロック解放待ち ( ビジーループ ) pthread_mutex_lock ビジーループの発生! クリティカルセクション pthread_mutex_unlock pthread_mutex_unlock 2016 Toshiba Corporation 12

Linux を適用して発生した問題と事例マルチコア環境では再現性が低い Proc A Proc B 優先度 99 優先度 98 Proc C 優先度 98 pthread_mutex_lock lock ロック変数 preempt wait ビジーループ! pthread_mutex_lock ビジーループ!

13 Linux を適用して発生した問題と事例マルチコア環境では再現性が低い Proc A Proc B 優先度 99 優先度 98 Proc C 優先度 98 pthread_mutex_lock lock ロック変数 preempt wait ビジーループ! pthread_mutex_lock ビジーループ! クリティカルセクション thread A スケジュール待ち therad B ロック解放待ち ( ビジーループ ) thread C ロック解放待ち ( ビジーループ ) クリティカルセクション wait pthread_mutex_lock クリティカルセクション pthread_mutex_unlock pthread_mutex_unlock pthread_mutex_unlock 2016 Toshiba Corporation 13

14 Linux を適用して発生した問題と事例要因は? ロック変数が4バイト境界に配置されていなかったこと pthread_mutex_lockの実装の問題 pthread inheritanceを使用していなかったという問題対策優先度を継承していれば問題は発生していなかったロック変数を4バイト境界に移動 pthread_mutex_lockの修正は難しい 2016 Toshiba Corporation 14

15 Linux を適用して発生した問題と事例発生条件まとめロック変数を4バイト境界に配置しない優先度の異なる複数のリアルタイムスレッドにて排他制御をする pthread_mutex_lockで排他制御をする pthread inheritanceを使用しない問題を引き起こした環境 Kernel : Linux rt31 UserLand : Debian Squeeze (eglibc ) 他の比較的新しい環境でも再現 Kernel:Linux UserLand:Ubuntu14.04 (glibc 2.19) 2016 Toshiba Corporation 15

16 Linux を適用して発生した問題の事例事例 2 e1000ドライバによるoops + カーネルパニック問題の概要 Linux 適用製品の連続通電にてカーネルパニック発生カーネルが出したバックトレースからe1000ドライバで発生していることを特定製品出荷後約 3 年後の出来事 2016 Toshiba Corporation 16

17 Linux を適用して発生した問題の事例問題に対するパッチはすぐに見つかったより引用 2016 Toshiba Corporation 17

18 Linux を適用して発生した問題の事例製品出荷から時間が経ち過ぎているこのパッチは製品で使用している Kernel に素直にあたってくれるだろうかパッチの内容を確認すると思ったより小規模これなら大丈夫! 2016 Toshiba Corporation 18

19 Linux を適用して発生した問題の事例新たな不安今回は大事を免れたが今後大きな修正パッチが出た時無事適用できるか Long-term support 版を使用する? Target kernel selection rules Maintainer will choose one LTS version per year Maintain it for 2 years from its original release より引用社会インフラシステムのライフサイクルはもっと長い 20 年前に出荷した製品の保守が必要になるケースがある 2016 Toshiba Corporation 19

20 まとめ社会インフラシステムへの適用で見えてきた点事例 1 より信頼性 linuxの信頼性はかなり高いアプリケーションの実装でも思いもよらない落とし穴がある設計段階で見つけにくい開発者の経験値は必要事例 2 より保守性メンテナンス期間はLong-term support 版の期間を上回る社内にOSSの動向をウオッチするメンテナが必須 2016 Toshiba Corporation 20

Insert your Title here

Insert your Title here マルチコアマルチスレッド環境での静的解析ツールの応用米 GrammaTech 社 CodeSonar によるスレッド間のデータ競合の検出 2013 GrammaTech, Inc. All rights reserved Agenda 並列実行に起因する不具合の摘出なぜ並列実行されるプログラミングは難しいのかデータの競合デッドロックどのようにして静的解析ツールで並列実行の問題を見つけるのか?