プロフィール

kosaki

Author:kosaki
連絡先はコチラ

ブログ検索
最近の記事
最近のコメント
最近のトラックバック
リンク
カテゴリー
月別アーカイブ
RSSフィード
FC2ブログランキング

スポンサーサイト このエントリーをはてなブックマークに追加

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


スポンサー広告 | 【--------(--) --:--:--】 | Trackback(-) | Comments(-)

[quilt tips] diffに賢く関数名を表示させる方法 このエントリーをはてなブックマークに追加

diffに-pがついてなくて見にくい。という苦情に対してquiltでのtipsの欧州。
たしかにラベルを除くのは理にかなってる


On Tue, 2010-10-19 at 12:47 +0200, Miklos Szeredi wrote:
> On Tue, 19 Oct 2010, npiggin@kernel.d wrote:
> > Index: linux-2.6/fs/fs-writeback.c
> > ===================================================================
> > --- linux-2.6.orig/fs/fs-writeback.c 2010-10-19 14:18:58.000000000 +1100
> > +++ linux-2.6/fs/fs-writeback.c 2010-10-19 14:19:36.000000000 +1100
> > @@ -288,10 +288,12 @@
>
> The function name here helps review a bit. If you are using quilt add
> "export QUILT_DIFF_OPTS=-p" to .quiltrc.

I have:

QUILT_DIFF_OPTS="-F ^[[:alpha:]\$_].*[^:]\$"



関連記事
スポンサーサイト
linux | 【2010-10-20(Wed) 13:37:04】 | Trackback:(0) | Comments:(0)

AKARI がどうやって、LSMフックの乗っ取っているのか調べてみた このエントリーをはてなブックマークに追加

NTTデータのTOMOYO Linuxのチームから (熊猫さくらさんの個人プロジェクトだったみたい。失礼しました)AKARIというセキュリティーモジュールがリリースされたようです。

http://permalink.gmane.org/gmane.linux.tomoyo.user.japanese/257

RHEL6でも動くと謳っていたので、軽く解析してみました。

モジュールロード時にsecurity_opsを使っている関数のアドレスを/proc/kallsyms
から取得し、その関数に対しバイナリ解析を行うことでsecurity_opsのアドレスを
算出し、上書きしているようです。

興味がある人は、ccs_find_security_ops() 近辺を読んでみるといいと思います。
バイナリ手法が面白いというか奇抜というか、いい感じなのですが、
Linuxカーネル本体に


int security_file_alloc(struct file *file)
{
return security_ops->file_alloc_security(file);
}

という関数があるので、


static int lsm_addr_calculator(struct file *file)
{
return ccs_security_ops->file_alloc_security(file);
}


というほぼ同じ関数を作ったら security_ops のアドレス以外は一致する
命令が出力される「はず」だから、関数の命令列を比較していって、不一致箇所を
security_opsだと仮定するという。そんなん。

# security_file_alloc()は公開関数なので/proc/kallsymsでアドレス取得できるしね

たぶん、コンパイラのバージョン合わせないとだめよね。これ。




関連記事
linux | 【2010-10-14(Thu) 10:52:25】 | Trackback:(0) | Comments:(0)

スラドねた 「今後のCPUのコア数増加とLinux」 このエントリーをはてなブックマークに追加

http://slashdot.jp/linux/article.pl?sid=10/10/01/2121208

スラドでLinuxが48コアまでスケールしないとか記事になっていたので元論文読んだ。なんだ、per-cpuカウンタ増やしてるだけじゃん。MITの論文にしてはショボイ。
えーと、従来多CPUマシンは主にHPC用に使われてきたのでVMまわりは多CPU考慮が山ほど入ってるけどVFSまわりは、そんなにクレイジーな実装ではなかったのね。その指摘は正しい。
でも、最近Nick Pigginが大幅にVFSのロックスキームを書き換えてスケーラビリティー問題を解決したので、この汚いFixは入る見込みがないんじゃなかろうか。
まあ、netdevまわりのfalse sharingの指摘とか細かいところは意味があるかも。

メモリ管理屋さん的には使った時間に見合う成果はなかったなぁ

関連記事
linux | 【2010-10-03(Sun) 02:04:59】 | Trackback:(0) | Comments:(0)
  1. 無料アクセス解析
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。