(toppers-users 3445) Re: タスクスタックの状況を確認するためのシステムコール実現の御提案

[Masaki Muranaka]

こんにちは．

> （瑣末に）反論すると

再帰的に瑣末反論するならば…

> そうなると、「タスクコンテキストで動作する」意義の議論が必要ですね。

(タスク例外の出自が"POSIXシグナルっぽいもの"への要求であるということに
間違いが無いとするならば，という仮定の基で，)そこを議論する必要，
ありますかねぇ…．
POSIXシグナルっぽくないところという線で検討の余地があるとしたら，
ブロック不可能なシグナルの扱いかなという気がします．
ブロック不可能なシグナルが飛んだ時，有無を言わさず実行単位を殺すのは
カーネルの仕事のはずです．
ならば，シグナルハンドラ相当のタスク例外ではなく，カーネルレイヤに
あるCPU例外に任せるのが順当なように思います．

タスク例外にマスク不可能なフラグを付けるという方針は有り得ますけれど，
結局，そのフラグを処理するのは，タスク例外処理ルーチンに移る前の
カーネル内処理になるのかなと思います．ならば，上記のようなCPU例外に
任せることになります．タスク例外の枠組みで無理しない(ユーザに委ねる)
ほうが，μITRON的な気がします．
// 直感です．

2011年5月1日15:19 SHUKUGUCHI Masahiro <shukuguchi ＠ biz.nifty.jp>:
> コメントありがとうございます。
>
> 動的検出方法をハードウェアまたはRTOS以外の責務にすることに依存はあり
> ません。しかし、規模（開発、予算等）や用途（要求される安全性等）によ
> り、それが適わぬこともあります。その点で、検討した際のソリューション
> として、これらの議論がなされていてもよいと思います。
>
> （瑣末に）反論すると
>> しかし，タスク例外はタスクコンテキストで実行されますので，スタックが
>> 溢れるかもという時に使うのは危険かもしれません．
> であれば、スタックオーバーフォロー寸前でのタスク例外処理ルーチンが呼び
> 出されるシチュエーションは考慮すべきことですので、実装としてタスク例外
> 処理ルーチンのスタックを別に確保して安全性を高める方式はあると思います。
>
> そうなると、「タスクコンテキストで動作する」意義の議論が必要ですね。
>
> さて、一方
>> そうでない場合もソフトウェア割込みなど使って非タスクコンテキストに
>> 移すほうが，より安全ではないでしょうか．標準化もしやすそうですし．
>
> はい。仰せのとおりです。
> 先のメールの議論を読み返せば、途中を端折っているところがありますね。
> CPU（および付随するハードウェア）または非タスクコンテキストでの検出が
> 前提で、そこからCPU例外ハンドラの起動に持っていくことを暗黙としていま
> した。
>
>
>> で，こういった案をどういうふうにフィードバックするのがよいのか
>> ということについてですが…
>
> はい。本題はこちらです。
>
> 実現というか問題解決のドメインとしては、、、
>
>> いずれの案にせよ，タスクスタックを扱う必要がありますので，
>> SILでカバーするのは難しいのではと思います．
>> 非タスクコンテキストについては SIL でイケるかもしれませんけれども．
>
> 現状カーネルとSILとの関連、切り分けの問題ですが、実装主体には乱暴に
> カーネルとSILとの通信手段を決めておくのも手かと思います。
>
>> とはいえ，カーネル仕様にできるかというと難しい気もします．
>> ガイドラインとかイディオムとか定石とかいう感じの文書になるの
>> かなと思います．
>
> カーネルAPI仕様の範疇か否かという観点では難しいですが、カーネルの責務
> をどのように捉えるか？で変わってくるようにも思います。
>
> しかし、現実解としては
>> ガイドラインとかイディオムとか定石とかいう感じの文書になるの
>> かなと思います．
>
> というところですね。
>
> # 藤倉さんへの返信に続く。
>
> Shukuguchi
>
>> こんにちは．
>>
>> 動的検出の方法は，ハードウェアに頼るか，GCC の -fstack-protector のような
>> ものを使うか，…いずれにしてもRTOS以外の何かにやらせたほうがよいでしょう．
>> (手埋めだと網羅確保の問題もありますし)
>>
>>
>> 発生時のカーネルの対応についてですが，POSIXシグナルとの類似性から，
>> タスク例外処理を使いたくなる気持ちは分かります．
>> しかし，タスク例外はタスクコンテキストで実行されますので，スタックが
>> 溢れるかもという時に使うのは危険かもしれません．
>>
>> ハードウェアの支援がある場合にはCPU例外が発生するでしょう．
>> そうでない場合もソフトウェア割込みなど使って非タスクコンテキストに
>> 移すほうが，より安全ではないでしょうか．標準化もしやすそうですし．
>> (非タスクコンテキスト内でタスクスタックの残量を見てから
>> iras_tex を呼ぶ，というパターンはアリでしょう．)
>>
>> スタックの残量は，バイト数で得られれば十分ではないでしょうか．
>> スタック用の配列の先頭番地/サイズとスタックポインタのアドレスは
>> 現在TOPPERSが対応しているアーキテクチャなら解りますよね．
>> スタック残量が僅少のときに関数を安全に呼べるかどうかは
>> アーキテクチャ(もしくはABIが規定するアラインメント)依存ですが，
>> 類似の問題はメモリプールでも起き得ますので，アプリ開発者の
>> 解釈に委ねるとしてもよいはずです．
>>
>>
>> で，こういった案をどういうふうにフィードバックするのがよいのか
>> ということについてですが…
>>
>> いずれの案にせよ，タスクスタックを扱う必要がありますので，
>> SILでカバーするのは難しいのではと思います．
>> 非タスクコンテキストについては SIL でイケるかもしれませんけれども．
>>
>> とはいえ，カーネル仕様にできるかというと難しい気もします．
>> ガイドラインとかイディオムとか定石とかいう感じの文書になるの
>> かなと思います．
>>
>>
>> 2011年4月26日22:59 SHUKUGUCHI Masahiro <shukuguchi ＠ biz.nifty.jp>:
>> > 宿口です。
>> >
>> > 有益なアイデアだと思うのですが、意外と冷たい（？）反応でしたね。
>> >
>> > 静的に、タスク設計時のスタック見積りは原則だと思います。
>> >
>> > 動的な防護策として、ディスパッチャ、システムサービスのエントリや割込み
>> > 処理の入口でのスタックチェックがあると良いと思います。これの課題（？）
>> > は、処理速度とスタックオーバフローを検出した場合の振舞いの定義ですかね。
>> >
>> > 処理速度は、コンパイルスイッチ等でスタックチェックの有効・無効を選択
>> > できれば問題は少なくなりそうですが、それだと、動的にチェックする動機が
>> > 薄れます。（信用の置けないアプリケーションを搭載するような場合だと特に）
>> >
>> > スタックオーバフロー検出時のカーネルの振舞いは、μITRON仕様の範囲では決
>> > めようが無いと思いますが、タスク例外処理の起動あたりが妥当と思います。
>> > しかし、タスク例外処理の起動はマスクできますし、そもそもタスク例外処理
>> > ルーチンが定義されていないと意味を成さないですね。
>> >
>> > また、カーネルで一意に振舞いを決めたくなりますが、カーネルに過度の機能
>> > を持たせることの懸念が生じるように思います。
>> >
>> > # だんだんネガティブになっていく。。。
>> >
>> > 一方、
>> > タスク観点では、タスク例外処理ルーチンでスタックオーバーフローを検出した
>> > 場合に状況を知りたくなりますので、その際や、デバッグ時にはスタック状況を
>> > 確認するインタフェースは有効だと思います。
>> >
>> > でも、CPUアーキテクチャに依存しますので、カーネルよりはSILあたりの
>> > 実装になりますか・・・ スタックの情報以外にカーネル等の資源状況を調査
>> > できるデバッギングパッケージなるものがあると、うれしいかもしれませんね。
>> >
>> > とりとめもなくすみません。
>> >
>> > Shukuguchi
>> >
>> >> 皆様
>> >>
>> >> 先日は多くの有用なアイデアの共有ありがとうございました。
>> >>
>> >> TOPPERSとしては今のところ「それはTOPPERSのサービスとして提供するものではない。」という認識に至りました。
>> >> このような機能については、先日高田先生から御指摘いただいたTECSを使って実装すれば良いのかもしれませんね。
>> >>
>> >> 中村晋一郎
>> >
>> >
>> >
>
>
>