LKML TOMOYO Linux Watch 39（仮設）
五回目の投降は２００７年１１月１７日に行われている。
今から思うと、４，５回目の投降が現在議論中の問題につながっているように思える。
[TOMOYO #5 00/18] TOMOYO Linux - MAC based on process invocation history.
http://lkml.org/lkml/2007/11/16/155
初めて-mmツリーに対してのパッチを投降している（要確認）。
-mmツリーというのは、この記事を好んで読むような人はご存知だろうが、採用段階準備段階に入った沢山のパッチの整合性などを確認するためのソースツリーで、Andrew MORTON氏が管理している（Andrew MORTON氏はakpmと呼ばれることがあるので以後akpmで通す。）。"-mm"というのは最初に開発されたのがメモリーマネージメントだったのでその名残である。git対応のlinux-nextやそのほかのことはの詳細は参考の[1]を参照すべし。
※あえて脚注機能をつかわないでみる
-mmにはakpm氏が直接選定したパッチが含まれることがあるため、選定されやすいようにTOMOYO Linux開発チームは最初から-mmツリー用のパッチを用意したようだ（要確認）。
AB-BA デッドロック回避のために構造体vfsmountをLSMへ渡すように改造
ここでいうAB-BAデッドロック問題は、インテルのArjan van de VEN氏に指摘されたている。TOMOYO Linuxは基本的にパス名が必要なので、パス名情報の検索・構築中に変化がないようにnamespace_semを使おうとしたが、デッドロックの問題が露見したのである（http://lkml.org/lkml/2007/11/5/388 ）。しかし、解決方法がすぐにしめされ、LSMがVFS情報をアクセスできるようにすればよいだけだ（see LKML TOMOYO Linux Watch 17/35）。
AppArmorの開発者達はメインカーネルに取り込まれるように努力したようであるが、適わぬと思ったのか、SUSEなどにはカーネルに独自のパッチをあてている（要確認）。しかし、このときから、TOMOYO Linuxの開発者達はこのVFS情報の受け渡しのパッチがメインカーネルに取り込まれるように努力することを本格的にはじめることになる（要確認）。
１番目のパッチにvfsmount情報がLSMに渡せるようにtask_structにあらかじめ最新のvfsmout情報を収める構造体を付加している。そうすれば、LSMにタスク構造体は渡るので、パス名検索ができるわけだ。２番目のパッチでラッパー関数を書いている。ところで、Linuxのカーネルソースってラッパー関数って当たり前にあるんだろうか？（要確認）３番目でラッパー関数を呼ぶように書き換えいるが、こういうのも当たり前にあるんだろうか？（要確認）。
***保守性を気にする人（仮）
上記のパッチに早速NACKを投げつけてきた人がいた（http://lkml.org/lkml/2007/11/16/170）。LinuxのNFSクライアント実装にフルタイムで貢献しているTrond Myklebust氏である（彼のサイト：http://www.trondhjem.org/、リスト未追加）。ミシガン州のCenter for Information Technology Integrationに在籍している方だ。スタックを通すやり方以外でtask_structを受け渡すやり方は絶対に受け入れられないとのこと。ここでいうスタックというのは、具体的には、おそらく、引数に持たせるという意味があるだろうか。はたまた、スタックメモリーに情報があればよいということであろうか（要確認）。
Myklebust氏は、last_vfsmountに新たに設定するコードが生じて整合性がとれなくなり保守性が損なわれることを指摘しているのであるが、半田氏が最初からユーザランドのプロセス由来の呼び出しシーケンスに対するパッチであることを説明していなかったために、当惑させたようだ。追加したのはラッパー関数であるから、カーネル内から呼び出しているときは従来のまま動くはずである。last_vfsmountに何かセットされたときに利用したいのはLSMフックポイント経由で呼び出されたTOMOYOのモジュールであるからだ。しかし、このようなものは一般的であるのだろうか？（要確認）。
ユーザーランド由来かカーネル由来かというのを突然だしたがために当惑させたが、呼び出しシーケンスが異なるのとlast_vfsmountによって区別が完全につけられる。また、vfs_mkdir()を直接呼び出す関数はその上位のsys_mkdirat()であるからラッパー関数を加えたところでユーザーランドのプロセスやカーネル内部からの整合性が崩れることはない（要確認）。
***ファイル・vfsmount・dentry、パス名についての復習
（のちほど）
未だに揉めてるリストの問題のはじまり
５回目の投降では、４回目の投降でJames MORRIS氏に指摘されて主張が理解されていないまま（see LKML TOMOYO Linux Watch 30）、要素を追加するときにRCUなどを使わずにmb()を使う独自の短方向リストを用意している。
